OAuth 2.0 Protocol with client app and Servers
OAuth
OAuth is a set of rules that allow you to share your data that you hold within an application with another application without revealing your user name and password that you hold within the first application with the second one.Roles
Client
The client is the application that is attempting to get access to the user's account. It needs to get permission from the user before it can do so.Resource Server
The resource server is the API server used to access the user's information.The Authorization Server
This is the server that presents the interface where the user approves or denies the request. In smaller implementations, this may be the same server as the API server, but larger scale deployments will often build this as a separate component.Resource Owner
The resource owner is the person who is giving access to some portion of their account.Authorization Code (or Web Server) Flow
The Authorization Code or Web server flow is suitable for clients that can interact with the end-user’s user-agent (typically a Web browser), and that can receive incoming requests from the authorization server (can act as an HTTP server).
The Authorization Code flow is as follows:
- The Web server redirects the user to the API Gateway acting as an Authorization Server to authenticate and authorize the server to access data on their behalf.
- After the user approves access, the Web server receives a callback with an authorization code.
- After obtaining the authorization code, the Web server passes back the authorization code to obtain an access token response.
- After validating the authorization code, the API Gateway passes back a token response to the Web server.
- After the token is granted, the Web server accesses their data.
Creating an App
Before you can begin the OAuth process, you must first register a new app with the service. When registering a new app, you usually register basic information such as application name, website, a logo, etc. In addition, you must register a redirect URI to be used for redirecting users to for web server, browser-based, or mobile apps.
OAuth 2 provides several "grant types" for different use cases. The grant types defined are:
Redirect URIs
The service will only redirect users to a registered URI, which helps prevent some attacks. Any HTTP redirect URIs must be protected with TLS security, so the service will only redirect to URIs beginning with "https". This prevents tokens from being intercepted during the authorization process. Native apps may register a redirect URI with a custom URL scheme for the application, which may look likedemoapp://redirect
.Client ID and Secret
After registering your app, you will receive a client ID and a client secret. The client ID is considered public information, and is used to build login URLs, or included in Javascript source code on a page. The client secret must be kept confidential. If a deployed app cannot keep the secret confidential, such as single-page Javascript apps or native apps, then the secret is not used, and ideally the service shouldn't issue a secret to these types of apps in the first place.Authorization
The first step of OAuth 2 is to get authorization from the user. For browser-based or mobile apps, this is usually accomplished by displaying an interface provided by the service to the user.OAuth 2 provides several "grant types" for different use cases. The grant types defined are:
- Authorization Code for apps running on a web server, browser-based and mobile apps
- Password for logging in with a username and password
- Client credentials for application access
- Implicit was previously recommended for clients without a secret, but has been superseded by using the Authorization Code grant with no secret.
Web Server Apps
Web server apps are the most common type of application you encounter when dealing with OAuth servers. Web apps are written in a server-side language and run on a server where the source code of the application is not available to the public. This means the application is able to use its client secret when communicating with the authorization server, which can help avoid some attack vectors.Authorization
Create a "Log In with mysell.lk" link sending the user to:
https://
localhost:8081/auth?response_type=code& client_id=CLIENT_ID&redirect_uri=REDIRECT_URI&scope=read
- code - Indicates that your server expects to receive an authorization code
- client_id - The client ID you received when you first created the application
- redirect_uri - Indicates the URI to return the user to after authorization is complete
- scope - One or more scope values indicating which parts of the user's account you wish to access
- state - A random string generated by your application, which you'll verify later
Get Authorization Code.
When user click Authorize Application, the service redirects the user-agent to the application redirect URI, which was specified during the client registration, along with an authorization code. The redirect would look something like this
"http://localhost:9999/oauth/access/?key=value"
Now Application request the Access token with authentication details, including the client secret, to the API token endpoint
"http://localhost:9999/oauth/access/?key=value"
Now Application request the Access token with authentication details, including the client secret, to the API token endpoint
Extract the access token
A successful response from the token request in the previous stage is JSON format data containing the access token. Your application parses the JSON to extract the OAuth access token.{
"access_token": "ACCESS TOKEN",
"token_type": "bearer",
"expires_in": 3000000,
"refresh_token": "REFRESH_TOKEN"
}
access_token
- The OAuth access token value.
token_type
- The Mendeley API issues bearer tokens so this value will always be `bearer`.
expires_in
- The remaining lifetime of the access token measured in seconds.
refresh_token
- if a refresh token was issued, it may be used to request new access tokens if the original token has expired.
- Here application is authorized!
- For sourcode Click here
Comments
Post a Comment