Understanding Oauth2 as a SSO

An Introduction to OAuth2

OAuth2 is an authorization protocol that allows third parties (clients) to access content owned by a user (hosted in trusted applications, server resources) without them having to drive or know the user’s credentials. That is, third-party applications can access content owned by the user, but these applications do not know the authentication credentials.

We are sure that everybody once have logged using “Login with Facebook” or “Login with Google”, as a user doesn’t pay attention how SSO works. They just want to use an application and they are thankful for a smoother experience and fewer logins and passwords.

In order to provide a user with a single sign on experience a developer needs to implement a SSO solution. This article is going to focus on OAuth2 protocol allows to have this login experience.

SSO Advantages

1. Reduces Help Desk costs: SSO helps users in order to not memorize a long list of passwords.
2. Improves customer satisfaction: A user-friendly login process can be very important because the login screen is where the first interaction between users and the inner halls of your website will be taking place. If those users are customers, you would want their experience to be great right from the start.
3. Boosts productivity: In companies implementing strict password policies, simple login processes can take much longer than usual. Users will have to take out their password lists, scan through it, and slowly key in each character into the password field. If the login fails, they’d have to check if they missed a character or keyed-in the wrong password.

As you can see SSO Advantages are quite good, now are going to present OAuth2.

Why OAuth2?

In this Introduction to OAuth2, first we will present to you the advantages of using this authorization protocol. The two major advantages are: it solves the problem of trust between the user and third party applications, and the second allows to the API provides third-party applications to share data of its users in a safe way, allowing to users make decisions about permissions and provide access to their data.

Trust or the lack thereof, is one of the most important reasons for implementing protocol authorization as OAuth2 reason. Lack of confidence from users with a third party application can guide the user wanting to allow the application to perform tasks and collect data on their behalf, but without giving the authentication credentials to the application.

Parties Involved

Owner resources:

It is an entity capable of providing access to protected resources. When a person will be referred to as an end user.

Customer:

It is the application that requests protected resources on behalf of a resource owner’s authorization.

Provider:

• Resource server. It is the entity that has protected resources. It is able to accept and respond to requests using an access token that must come in the body of the request.
• Authorization server. Usually the authentication server is the same as the resource server. The authentication server is responsible of generating tokens to allow access and authenticate users and credentials.

Workflow

• A. The client requests authorization from the resource owner. The request may be made directly to the authorization server instead of the resource owner.
• B. The resource owner grants authorization to access using one of the four types of available authorizations (authorization code, implicit, resource owner password credentials or client credentials).
• C. The client asks the server access authorization token, identifying and presenting the authorization code obtained in step B.
• D. The authorization server validates client’s credentials and authorization code. After they are validated, it returns a valid access token.
• F. The client and server resources are already able to exchange secure requests with the access token to serve protected content.

Considerations for use.

Client server resources

A customer must be registered in the resource server you want to access. A customer is identified by a client_id and usually with a plus redirection URLs to use in the exchange of tokens and access client_secret. The process of registering a new client is not defined in the specifications of OAuth2. The server resources is in charge for requesting the data needed to register a client.

OAuth2 defines two types of clients depending on their ability to maintain client credentials safe and not exposed. Client types are:

• Confidential: Those customers who are able to maintain authentication credentials secure and confidential. These customers are those who are implemented on secure servers.

• Publics: There are customers who are unable to maintain the confidentiality of credentials. Customers are the pure web (browser-based-app) or native terminal applications and devices.

EndPoints on the Service Provider

The provider can define two endpoints to allow all authorization flow-validation (in some cases both are necessary and in others only the token-endpoint necessary). One of them will be responsible for authentication, credential validation and the other will be responsible for issuing access tokens.

• Authorization endpoint: This access point should be responsible for validating the clients and resource owners. When a client wants to access a resource, it is at this point where the provider validates both the client and the owner, it generates concessions to access protected resources. Normally gets (apart from the necessary credentials) a URL redirection to redirect the flow once the owner and the client have been validated, when this happens, the url redirection receive the concessions (usually in code format).

• Token endpoint: this point is responsible for giving access tokens, usually in exchange for concessions previously issued by the Authorization end-point.

Getting permission to access the protected resourcer

When a customer wants to access resources on an owner, the first thing you need is to request permissions to the owner of the resource. This step is called Authorization Grant. For a resource server give you an access token, it is essential to submit an Authorization Grant credentials with the client attempting to access the data. A service provider does not have to necessarily implement all types of concessions (Grant Type).

There are four types of Authorization Grant defined by OAuth2 and they determine how to get a valid access token. Each of the types of authorization is designed to meet the needs of different types of customers.

Scope Permission

OAuth2 defines a parameter that can be involved in negotiating authorization called scope. The provider is responsible for defining different scopes and how to obtain permission to access each of them. Through a mechanism Scopes gets to define the range of access granted to the customer and can give access only to certain system resources.

Authorization Grant

Authorization Code

This type of access is used when trying to access the web application server resources. (Server to Server). We must always keep in mind that the Resource Owner authenticates and validates the authorization server and credentials are never exposed to the client. Once the owner of the resources has been authenticated and validated by the provider, by redirect URL returned to the client an access code that can be exchanged for access Token.

• A.The client initiates the flow directing the user agent (browser) to the resource owner authorization endpoint. The client includes the client_id, scope of the authorization and the url to which the authorization server should redirect the end of the request.
• B.The authorization server identifies the owner of the resource using the browser, and establishes if the owner gives permission or not the client.
• C. Assuming that the owner has granted permission, the authorization server redirects the user-agent owner to redirect_uri sent in step A. In this redirection includes an authorization code valid to interchange for an access token authorization.
• D. The client makes a request at the tokens endpoint, informing their credentials and authorization code.
• F. The authorization server verifies the credentials and the authorization code, and if successful returns a valid access token..

Implicit

This method is used primarily in client applications (browser-based-application) to reduce the number of calls. This Authorization Grant is the least secure of all, because the double checking is avoided.

• A.The client requests the authorization server an access token.
• B. The authorization server validates client credentials, Therefore returns directly valid access token.

Resource Owner Credentials

This type of authorization is used when the user trusts the client enough to give their login credentials to Server Resources. These credentials are not stored on the client side only is used to obtain an access token. This type of authorization is used mainly in mobile applications where the application once downloaded to the terminal, the credentials are entered only once.

• A.The client requests the authorization server an access token by directly sending user credentials resource owner.
• B. The authorization server then validate client credentials, returns directly valid access token.

Client Credentials

In this scenario only client and server authorization participate(2-legged). Is used when the same client who wants to access server data without authorization to do so on behalf of a resource owner. The flow that is defined for these cases is exactly the same as for the previous case, only client credentials are used directly instead of resource owner.

Getting a new access token

The access token must have an expiration date after they are considered expired , the provider must reject this request, forcing the client to obtain a new access token. To avoid re-doing all the validation process necessary for obtaining the token, it is convenient to use Refresh Token mechanism. Where the authorization server provides an access token, you can include a refresh token associated with the access token.

With the refresh token mechanism is possible to generate a new access token, using the refresh token generated in the previous client validation made by the resource owner.

• A. The client requests an access token to provider, presenting an Authorization Grant.
• B.The authorization server validates the request and returns an access token.
• C. The client requests the resource to the server resources presenting the access token.
• D. The resource server validates the access token and if valid returns protected resources.
• E. Steps C and D are repeated until the resource server detects an expired or invalid token access. When the customer response invalid access token jumps to step G.
• F. When the access token is invalid resource server informs the client.
• G. The client makes a request to obtain a new access token presenting the refresh token.
• H. The server authenticates the client authorization and validates the refresh token. If everything is valid, returns an access token and optionally a refresh token.

Conclusion

Finally, using OAuth2 in an application provides a higher level of usability for end users of our applications so they will feel much more comfortable to use with their favorite social network or with the security that you can use the application without new credentials.

The implementation of OAuth2 is relative simple and covers most of the scenarios that you could face, using this feature in the development of a web or mobile application will ensure a larger number of users, which means a better market raking.

Here at ClickIt, OAuth2 protocol is implemented in several customer applications. We have the knowledge to develop, build and architect a custom authentication mechanism which can empower the security in a complex environment with multiple RESTful APIs. Don’t hesitate to ask our approach and how we implement this solution”.