This article Outlines the OAuth 2.0 protocol. It discusses the different actors and steps involved in the OAuth 2.0 implementation process.
Introduction:
OAuth stands for open licensing. It is a free and Open protocol based on the IETF standard and the Open Web Foundation license. It allows users to share their private resources with third parties while keeping their credentials private. These resources can be photos, videos, contact lists, location and billing capabilities, and are often stored with other service providers. OAuth does this by granting a token to the requesting (client) application when the user grants access. Each token grants limited access to a specific resource for a specific period of time.
1. Oauth2 is an authorization protocol:
OAuth2 supports “delegate authentication,” which grants access to other people or applications to perform actions on your behalf. Consider this situation: You drive to an elegant hotel, and they may offer valet parking. You then authorize the valet to drive by handing him the keys so that he can perform the operation on your behalf.
OAuth2 works in a similar way – the user grants access to the application to perform limited actions on the user’s behalf and revoks access if access is suspect.
2. Participants in OAuth2:
I) Resource server: a server that hosts user-owned resources protected by OAuth2. The resource server validates the access token and provides protected resources.
Ii) Resource owner: In general, the user of the application is the resource owner. Resource owners can grant or deny access to their own data hosted on the resource server.
Iii) Authorization Server: The authorization server obtains the consent of the resource owner and issues an access token to the client to access the protected resources hosted by the resource server.
Iv) Client: The application enables API requests to perform operations on protected resources on behalf of the resource owner. Before it can do so, it must be authorized by the resource owner, and authorization must be verified by the resource server/authorization server. OAuth2 defines two client types based on its ability to securely authenticate with the authorization server (that is, its ability to maintain the confidentiality of its client credentials) :
A) Confidentiality: The client can maintain the confidentiality of its credentials. A confidential client is implemented on a secure server with limited access to client credentials (for example, a Web application running on a Web server).
B) Public: the client cannot maintain the confidentiality of its credentials (for example, installed native applications or Web browser-based applications) and cannot secure client authentication by any other means.
3. You are an application developer and this is a use case:
Consider a scenario. You’re developing a fun Facebook application and calling it “FunApp.” FunApp requires access to a user’s public profile, photos, posts, friends, etc. Now the question is, how does FunApp get the user access to his/her data from Facebook, and at the same time tell The Facebook user that FunApp has granted the user access so that Facebook can share the user’s data with the application?
The old way: the user shares his/her Facebook credentials (username, password) with FunApp. There are some challenges to this approach: trust, unrestricted access, user changes to Facebook passwords, etc.
OAuth2: If the app needs access to its user data, Funapp redirects the user to an authorized page on Facebook. The user will log in to their account and grant access, and FunApp will then obtain an access token from Facebook to access the user’s data. While Oauth2 has addressed these challenges, it also creates costs for developers.
Let’s look at the scene from a developer’s point of view and identify the actors involved:
- Because Facebook owns all the resources (users’ public profiles, photos, posts, friends, etc.), it becomes a resource server.
- The user is the resource owner.
- When FunApp requests a user’s protected resource, it becomes the client.
- When Facebook obtains user consent and issues an access token to FunApp, it becomes an authorization server.
4. Register client (FunApp) and obtain client credentials:
OAuth requires clients to register with the authorization server. The authorization server requests some basic information about the client, such as name, redirect_URI (the URL that the authorization server redirects to when the resource owner grants rights) and returns the client credentials (client-id, client-secret) to the client. These credentials are critical to protecting the authenticity of requests when performing operations such as exchanging authorization codes for access tokens and refreshing access tokens.
For example, Facebook requires you to register your client on the Facebook Developers portal. Go to the Facebook Developer portal and sign up for FunApp and get client credentials.
5. Step by step access token:
FunApp needs an access token from Facebook to access users’ data. To get access tokens, FunApp redirects users to Facebook’s login page. After a successful login, Facebook redirects to the Redirect_URI (registered in Step 4) and the short-term authorization code. FunApp exchanges authorization codes to obtain long-term access tokens. Access tokens are used to access the user’s data. This is the most popular process in OAuth2 and is called authorization code authorization. Here is the sequence diagram for obtaining access tokens in authorization code authorization:
6. Understand authorization Authorization types:
To obtain access tokens, the client obtains authorization from the resource owner. Authorization is expressed in the form of authorization, which is used by the client to request access to the token. OAuth2 defines four standard authorization types: authorization code, implicit, resource owner password credentials, and client credentials. It also provides an extended mechanism for defining other types of authorization.
I) Authorization Code Authorization: This authorization type is optimized for confidential clients (Web application servers). Authorization code flows do not expose access tokens to the resource owner’s browser. Instead, authorization is done using an intermediate “authorization code” passed through the browser. This code must be exchanged for an access token before a call can be made to the protected API.
Ii) Hidden Grant: This grant type is applicable to public customers. Implicit authorization processes do not apply to refreshing tokens. If the authorization server periodically expires access tokens, your application will need to run the authorization process as long as access is required. In this process, the access token is returned to the client immediately after the user grants the requested authorization. No intermediate authorization code is required because it is in the authorization code authorization.
Iii) Resource owner password certificate: The resource owner password certificate authorization type applies to the situation where the resource owner has a trust relationship with the client and the resource owner agrees to share his or her credentials (user name, password) with the client. The client can then obtain access tokens from the authorization server using resources in the owner credentials.
Iv) Client credentials: This type of authorization is appropriate when the client owns the data itself and does not require delegated access from the resource owner, or has granted delegated access to the application outside the typical OAuth process. In this process, no user consent is involved. Clients exchange their client credentials to get access tokens.
7. Token has expired, get a new access token:
API calls using OAuth 2.0 access tokens may encounter errors if the access token is no longer valid because the token has expired or been revoked. In this case, the resource server will return a 4XX error code. The client can obtain a new access token using the refresh token (obtained when the authorization code swaps the access token).
8. Conclusion:
This is an attempt to provide an overview of the OAuth 2.0 process and provide methods for obtaining access tokens. I hope it helps.
Enjoy the fun of integrated apps!
dzone.com/articles/oa…
See more articles
Public id: Galaxy 1
Contact email: [email protected]