Oauth2.0 is very simple with spring-security-oauth2 __oauth

Last week, I wanted to develop an example of OAuth 2.0. I checked the spring-security-oauth2.0 sample, OAuth 2 provider SPARKLR2 and OAuth 2 client Tonr. I explored the internet for a moment, sorting out the relevant documents. Compile and run the OAuth 2 provider SPARKLR2 and OAuth 2 client Tonr and check all authorizations. Now, I'm here to understand spring-security-oauth2.0 from a practical perspective on the different aspects of OAuth 2.0.


This article is an attempt to describe the OAuth 2.0 in a simplified form to help developers and service providers implement the agreement.

I will cover the following topics in this article.

1. Entity
2. Creating an Application
3. Authorization, Grant-type
A.web Server application (WEB server)
B. browser-based applications (Web Client)
C. Mobile Apps
D. Other desktop applications
4. Access resources
5. Resources


OAuth2.0 Process:

OAuth server:
This is also known as the provider of OAuth. Its overall responsibility is to authenticate and authorize the user/client and manage the token.

Third-party applications:
Third-party applications, commonly known as clients, will attempt to gain access to the user's account. It needs permission from the user before it can do so. This could be a web-based application, browser-based applications, desktop applications, mobile/tablet applications or some smart devices such as Google Goggles and smart TVs.

Resource server:
The API, commonly known as a resource server, from which data is extracted or delivered. This may be the underlying service provider for soap or rest.

User:
Users are commonly known as resource owners who have access to access resources.

To create an application:

You must register a new application and service/vendor before you start OAuth. When registering a new application, you typically register basic information, such as application Clint ID, secret, grant, type, and so on, in addition, you must register a redirect URI to redirect the user to a Web server, browser-based, or mobile application.

Redirected URI:
The service will only redirect users to the registered URI, which helps prevent certain attacks. The URI of any HTTP redirection must be secured with SSL, so the service will only be redirected to a URI that starts with "https." This prevents the token from being intercepted during the authorization process.

Client ID and Authorization password:
After registering your application, you will have your client ID and client authorization password. The client ID is considered public information and is used to establish a login URL, or to include JavaScript source code on a page. The client authorization password must be kept confidential. This authorization password is not used if the deployed application cannot maintain confidentiality of the authorization password, such as JavaScript or native applications.

Authorization mode:

The first step in OAuth 2 is to obtain authorization from the user. For browser-based or mobile applications, this is usually achieved by the interface displayed to the service provided by the user.

The OAuth 2 provides a number of different batch types for use cases. The types of grants defined are:

The application authorization code running on a Web server
Implied browser-based or mobile applications
Password and username and password login
For application access client credentials

Web server Application
Web applications are written in a server-side language and the source code of the application running the server is not available to the public.

Authorization Request:

http://localhost:8080/oauth2/oauth/authorize?response_type=code&client_id=easylocate&scope=read& Redirect_uri=http://localhost:8080/web

To receive access later. The page will be redirected to the authorization code of the redirected URI.

Http://localhost:8080/web/?code=t7ol7D

It's time to swap the authorization codes to get access tokens.

http://localhost:8080/oauth2/oauth/token?grant_type=authorization_code&code=t7ol7D&redirect_uri=http:/ /localhost:8080/web&client_id=easylocate&client_secret=secret

Server reply to OAuth with access token

{
"Access_token": "372c3458-4067-4b0b-8b77-7930f660d990"
"Token_type": "Bearer",
"Refresh_token": "Ce23c924-3f28-456c-a112-b5d02162f10c"
"Expires_in": 37364,
"Scope": "read"
}

In case of wrong authorization code, the OAuth server replies to the error.

{
"Error": "Invalid_grant",
"Error_description": "Invalid Authorization code: T7old"
}

Security: It is important to note that the service should require the application to have a pre-registered, redirected URI. Otherwise there will be a mismatch.

browser-based Applications and mobile applications:
The browser-based application runs completely after the source code that the browser loads from the Web page. Since the entire source code is provided to browsers, they cannot maintain confidentiality of their client secrets, so this secret is not used in this case.

Authorization Request:

Http://localhost:8080/oauth2/oauth/authorize?response_type=token&client_id=easylocate&redirect_uri= Http://localhost:8080/web&scope=read

To receive access later. The page will be redirected to the redirected URI and token.

http://localhost:8080/web/#access_token =372c3458-4067-4b0b-8b77-7930f660d990&token_type=bearer&expires _in=37026

That's it, there's no other step. At this point, some JavaScript code can pull a fragment of the access token (in the back part of the #) and start making API requests.

If an error occurs, you will instead receive an erroneous URI fragment, such as:

http://localhost:8080/web/#error =invalid_scope&error_description=invalid+scope:+rea&scope=read+write

Based on Password:
The OAuth 2 also provides a direct exchange of a username and password-delivery for the token. Because this obviously requires an application to collect the user's password, it should only be used for applications created by the service itself. For example, native Twitter applications can log on using this money-type mobile or desktop application.

Using a password delivery, just make a POST request similar to the following. I now use the crimp tool to demonstrate the POST request. You can use any of the remaining clients.

Curly-i-x post-d "client_id = easylocate & grant_type = password and username admin and password = admin & client_secret = secret" Http://localhost:8080/oauth2 /oauth/token

The server will return the token

{
"Access_token": "4E56E9EC-2F8E-46B4-88B1-5D06847909AD"
"Token_type": "Bearer",

   "Refresh_token": "7e14c979-7039-49d0-9c5d-854efe7f5b38"
   "expires_in": 36133 ,
   scope: Read,write
}

Client credentials are based on:
Client-credentals Authorization for server to server application access. I'm just representing a POST request using the Curl tool.

Curly-i-x post-d "client_id = easylocate & grant_type = client_credentials & client_secret = secret" Http://localhost:8 080/oauth2/oauth/token

The server will return the access token
 {
   "Access_token": "9cd23bef-ae56-46b0-82f5-b9 a8f78da569 "
  " Token_type ":" Bearer ",
  " expires_in ": 43199,
  " Scope " : ' Read '
}

Access resources:

Once you have authenticated and obtained an access token, you can provide access tokens to access protected resources.