OAuth 2.0 | Scopes, Roles & Grant Types
With understanding of what is OAuth and tokens in last two articles: https://www.techlearnings.org/single-post/oauth-2-0-is-it-an-api-or-service-what-is-oauth-actually , https://www.techlearnings.org/single-post/oauth-2-0-access-refresh-tokens , time to understand few more key concepts - Scope, Roles and Grant Types. This article might seem a bit theoretical but these are key concepts which we must grasp to continue our OAuth journey.
Scopes: are the bunch of permissions which client will have once the token is granted. e.g. In image below, name, email address etc. are the allowed scopes. Similarly, there can be denied scopes as well; which will inform the client that you're not allowed to access following information. In short, scopes signify permissions for which user has provided consent.
Roles: are more or less covered in last article but formally introducing them here. OAuth defines following four roles :
Resource Owner: represents an entity which has capability to grant access to a protected resource.
Resource Server: represents the server where the protected resource resides.
Client: represents an entity which requests for protected resource on behalf of the owner and with its authorisation.
Authorisation Server: represents the server which issues access token to the client and guarantees authorisation.
Same server can act as Authorisation server as well as resource server or both can be separate entities as well.
Let's try to visualise roles with below image -
Grant Type: represents the way how an application gets access tokens. In other words, what steps the client needs to perform in order to get resource. The OAuth framework defines four different grant types with support to add more, if required.
Authorisation Code Grant: In this case, the client redirects the resource owner to authorisation server which in turns redirects the owner back to client with a one-time use authorisation code. The client can further use that code to get an access token.
Implicit Grant: In this case, the client is issued an access token directly instead of authorisation code. This is generally suitable for clients implemented in a browser using scripting languages such as JavaScript. The auth server does not authenticate the user before issuing the token which makes it less secure. (We'll study more about token misuse in later articles)
Resource Owner Password Credentials: In this case, the resource owner shares username and password with the client which then uses them to get an access token from auth server. As credentials are shared, therefore the client should be highly trustworthy.
Client Credentials: In this case, there is no user interaction e.g. backend service to service communication. The client simply uses its credentials (client id and secret) to get an access token.
Instead of Authorisation Code Grant, it's recommended to club it with Proof Key for Code Exchange (PKCE) to prevent CSRF and authorization code injection attacks.
I know it's a bit difficult term to digest, but let's keep it simple for now - we should always use Auth Code Grant with PKCE. (Would request to read by yourself about it, else we might deviate from our main topic for this article)
Two more key terms before we sign off for today:
Public Client: refers to client applications that run on devices/desktops or web browsers. These can't keep the application secrets securely with them, hence generally access only web based APIs on behalf of user. e.g. Desktop/Mobile apps.
Confidential client: refers to client applications that generally run on servers. These are more secure as compared to public clients, and thus can keep application secrets. e.g. Web App, Web API, Daemon/service
OAuth is a vast concept, much more to cover in subsequent articles, stay tuned!
Happy Learning!
Comments