In this article, we would like to provide an overview of what is OAuth 2.0 and the concepts like scopes, Grant Types we must aware of before proceeding with OAuth 2.0.
What is OAuth 2.0?
OAuth 2.0 is an authorization framework that allows users to grant a third-party website or application to access the user’s protected resources without revealing their credentials or identity. For that purpose, an OAuth 2.0 server issues access tokens that the client applications can use to access protected resources on behalf of the resource owner.
OAuth Scopes
OAuth 2.0 scopes provide a way to limit the amount of access that is granted to an access token. When the app requests permission to access a resource through the Authorization server, it uses a scope parameter to specify what access it needs, and the authorization server uses the scope parameter to respond with the access that was actually granted.
OAuth 2.0 Terminology
Resource Owner : the entity that can grant access to a protected resource. Typically this is the end-user.
Resource Server (API Server): The server that is hosting the protected resources, capable of accepting and responding to protected resource requests using access tokens.
Client : An application making protected resource requests on behalf of the resource owner and with its authorization. The term client does not imply any particular implementation characteristics (e.g. whether the application executes on a server, a desktop, or other devices).
Authorization Server : The server issuing access tokens to the client after successfully authenticating the resource owner and obtaining authorization.
OAuth Grant Types
OAuth 2.0 provides below-mentioned grant types (“methods”) for a client application to acquire an access token that can be used to authenticate a request to API endpoints / other integrations.
- Authorization code grant flow with PKCE ( P roof K ey for C ode E xchange)
- Authorization code grant flow
- Client credentials grant flow
- Implicit grant flow
- Resource owner credentials grant flow
Authorization code grant flow with PKCE (Proof Key for Code Exchange)
Please do note that the Authorization code grant flow is considered insecure without PKCE.
Before the introduction of PKCE, Authorization code grant flow is not recommended to use along with SPAs implemented using JavaScript frameworks. Traditionally the Authorization Code flow uses a client secret when exchanging the authorization code for an access token, but there is no way to include a client secret in a JavaScript app and have it remain a secret.
The above-mentioned issue is applicable to mobile native apps as well. In mobile apps, by decompiling the app, you can view the client secret. Thankfully OAuth team has solved the issue by extending the Authorization Code flow with PKCE extension.
The Authorization Code flow with PKCE adds an additional step which allows us to protect the authorization code so that even if it is stolen during the redirect it will be useless by itself.
The key difference between the PKCE flow and the standard Authorization Code flow is users aren’t required to provide a client_secret. PKCE reduces security risks for native apps, and SPAs as embedded secrets aren’t required in source code, which limits exposure to reverse engineering. Client_secret is used by the Authorization server to identify the client who is making the request.
In this approach, the client first generates a runtime secret called the code_verifier. The client hashes this secret and sends this value as code_challenge as part of the frontend request. The Authorization server saves this value. The client includes the code_verifier as part of the subsequent code exchange request. The Authorization server compares the hash of the code_verifier with the original code_challenge it received.
How does It work?
Authorization Code flow with PKCE is recommended for Mobile Apps, SPAs. If your application can secure the ‘Client_secret’, you can opt-in for Authorization code Flow
Authorization code grant flow
Authorization code grant flow is used in web apps are server-side apps where the source code is not publicly exposed. Your application must be server-side because, during this exchange, you must also pass along your application’s Client Secret, which must always be kept secure, and you will have to store it in your client.
How does It work?
Authorization code grant flow is recommended to use with the web apps that are server-side apps where the source code is not publicly exposed.
Client credentials grant flow
Client credentials grant flow allows a web service to use its own credentials, instead of impersonating a user, to authenticate when calling another web service. In the approach, the client (Daemon service, Cron job) sends the credentials to the Authorization server, on successful authorization; the authorization server sends back the access token to access the resources.
How does It work?
Client credentials grant flow is recommended to use to run the scheduled jobs or authenticating the external systems requests / Remote API calls.
Implicit grant flow
The Implicit grant type is used to requests the access tokens directly from the authorization server, without the use of the authorization code or client_secret. It is recommended to use as part of JavaScript applications like Angular or React JS applications. This grant type does not include client authentication because the client_secret cannot be stored safely on the public client. This grant type relies on the callback URL given when the client was registered, to validate the identity of the client.
How does It work?
Before the Introduction of Authorization code flow with PKCE, Implicit grant flow is recommended for SPA and Mobile applications where client secrets cannot be kept secret.
Resource Owner Credentials Grant flow
The Resource Owner Password Credentials flow allows exchanging the username and password of a user for an access token. In the grant flow, the client application accepts the user credentials (User Id and Password) in an interactive form (Login page) and sends over to the authorization server for validation. The authorization server validates the credentials and responds back with an access token.
The resource owner password credentials grant type is suitable in cases where the resource owner has a trust relationship with the client, such as the device operating system or a highly privileged application.
It is recommended only for first-party “official” applications released by the API provider.
How does It work?
This is not recommended to use with the client as it imposes additional security issues as the user entering the user id and password on an external login page. This is only recommended for the products from the Authorization Server.
Thank you for reading the article. Please share your thoughts in the comments box. If you like our article, please share it.
References:
https://auth0.com/docs/flows https://docs.wso2.com/display/IS530/Working+with+OAuth
Originally published at http://www.techmonks.org on July 17, 2020.
Top comments (0)