Apache Oltu OAuth 2.0 Client License: Apache 2.0: Tags: authentication apache client oauth: Used By: 197 artifacts: Central (4) ICM (1). This article shows you how to use Apache HttpClient to send an HTTP GET/POST requests, JSON, authentication, timeout, redirection and some frequent used examples. P.S Tested with HttpClient 4.5.10. HTTP Basic Auth. HTTP Basic Auth is a simple method that creates a username and password style authentication for HTTP requests. This technique uses a header called Authorization, with a base64 encoded representation of the username and password. Depending on the use case, HTTP Basic Auth can authenticate the user of the application, or the app.
An overview on the OAuth2 security authorization protocol and its implementation with Apache CXF.
OAuth and OAuth2 protocols are two successive versions of an open protocol that allows you to protect your valuable web application resources against an unauthorized access, in a simple and standard method. In this post, we will assume that the resources to be protected are being served by a set of Restfull web services. These Restfull are supposed to be taught, how to protect the resources that they serve in order to assuming the responsibility of judging an access request, and deciding whether to accept it, or to reject it.
OAuth2 is the second and latest version of this protocol that enables a third-party application to obtain limited access to an HTTP service, either on behalf of a resource owner by orchestrating an approval interaction between the resource owner and the HTTP service, or by allowing the third-party application to obtain access on its own behalf.
OAuth2 is built in a ReST like fashion, yet it is not truly adopting all of the ReST architectural style principles. This is mainly because it is based on the idea of keeping the state of the client on the server side, so it possesses some sort of statefulness flavor which in fact does contradict with the statelessness nature of ReST architectural style.
What happens with the OAuth and the OAuth2 protocols, is that the server keeps some information about the client, like its grant code, and the corresponding tokenlinked with a set of permissions, describing the authorization scope of the client. The intent behind this approach, is to ward off the need for a heavy and fully informative request with every interaction between the client and the server carrying all of the needed information encapsulated in one request.
The primary concern addressed by this protocol is to verify the identity of a client application asking for a specific level of access on a particular protected resource. Once the identity is verified, and the client application is authenticated, it can then be authorized to get the required scope of access, and this is secondary concern addressed by this protocol.
Entities are the different participants, assuming different roles, yet collaborating together in a typical OAuth2 protocol scenario.
1- Resource Owner
This is the owner of the resource that has to be protected. It is actually the one who takes the final decision about whether to grant access on the resource, or to reject the request, and decide to conceal the resource from the outside world
2- Resource Server
This is place that hosts the resources that are required to be protected, where the data will be fetched out or served. This could be the SOAP or REST based service providers.
3- Client Application (Third Party Application)
Represents the application that requires to get access on a particular resource that is owned by the resource owner and hosted by the resource server.
4- OAuth2 Server (Authorization Server)
Responsible for the handshaking phase, where the client and the server agrees on a specific access token, that can then be used during the communication between the Client and the Resource Server.
In some cases, it might appear that there is no emergent need to separate the Resource Owner from the Authorization Server. They can be both blended in one thing, with their corresponding responsibilities being carried out by a single entity.
An example for this mix, is when your architecture is such that a single channel being in charge of exposing your valuable resources to the outside world, while at the same time, it assumes the responsibility of judging the external client who asks for access grant to a particular resource, and thus to decide whether to hand it to the client or to keep it away and continue to protect it from an access that is deemed unauthorized.
The OAuth2 protocol incorporates a Handshaking Phase, required to precede the Communication Phase.
In the next two sections we will get off the cover, and start to explore what takes place between the client and the server within these two phases.
1- Handshaking Phase
The handshake phase establishes the infrastructure of the communication channel that would take place right after the this phase is complete. The output of the handshake phase is an AccessToken, granted for an authorized client. The AccessToken, is in fact the underpinning of the subsequent communication between the client and the server.
Before the Handshaking phase can even start, each client application expected to have access on any protected resource hosted by the Resource Server, shall be handed a pair of client id/client secret. This should be done out of band, before the OAuth protocol can even make any advancement. Worth mentioning here, that the absence of a client id/client secret assignment, will result in an unsuccessful attempt to authorize a client who is trying to get access on a protected resource. The client id and the client secret, together help the Authorization Server to identify the client that it is talking to, and can then be able to verify its authorization.
The handshaking phase is further decomposed in two primary stages. These are the Authorization stage and the Token Grant stage.
While the Token Stage is intrinsically compulsory, the Authorization Stage is not. That’s because, the functionality of authorization can be implicitly carried out within the token stage.
1.1. Authorization Stage
OAuth2 provides a multitude of grant types that can be used to authorize the client that is calling for an Access Token. During the Authorization part of the handshake phase, the authorization server authenticates the client and verifies that it is really the client that it is claiming to be, and not someone else who is just trying to deceive both the resource server and the resource owner.
Below is a quick list of the supported Grant Types
- Authorization Code
The client application asks the server to provide it with an authorization grant code which can then be used to request a top-secret AccessToken.
Assuming that our client application is called ‘X’, and has been handed a client id ‘1’.
This is how an Authorization request issued by the client and submitted to the authorization server would typically look like:
http://localhost:8080/oauth2/authorize?response_type=code&client_id=1&scope=read_user_profile&redirect_uri=http://localhost:8080/X/authorization/code
After identifying the client using its id (client_id), the Authorization Server will generate an authorization grant code and post it on the URI passed in the original authorization request (redirect_uri).
And the header of the HTTP request looks like:
The Authorization header, encapsulates the encoding of the client id and client secret, so that the authorization server can initially authenticate the issuer of this request, and can generate an authorization code accordingly.
The Authorization server uses the redirect_uri passed in the request query parameters, to post the generated authorization code.
The response received from the Authorization Server will look like:
Authorization Code Posted Back
The granted authorization code can then be exchanged with the Authorization server in order to get the access token.
- Implicit Authorization
- Client Credentials
The client application will just be providing a User Name and a Password credentials to get hold of an access token that can be used in further communication with the resource server.
- Resource Owner / Password Credentials
The credentials of the owner of the resource are being used to verify the identity of the client application.
- Refresh Tokens
The client application will just be requesting to refresh a token that has been in use already, and which has turned out to be invalid for some reason, either revoked or expired or any other reason.
- Assertions
Spring Oauth2 Client
SAML 2 assertions can be used as a grant type that allows the authorization server to verify the identity of a client requesting an access token
- Custom Grant
If we need to customize the way the well-known grant requests are handled then we can consider extending one of the grant handlers listed above.
1.2. Token Grant Stage
Python Oauth2 Client Example
An Access Token, is meant to be used as a secret key that is only known to the client, the authorization server and the resource server. No one else is supposed to get hold of this token for the entire period of time, during which this token is judged to be valid.
Access Token is associated with a set of authorized permissions that the candidate owner of this token will be entitled for. These are represented by the CXF class (“org.apache.cxf.rs.security.oauth2.common. OAuthPermission”).
This class provides the complete information about a given opaque permission. It wraps a set of HTTP verbs and a set of request URIs that are considered to be permitted for this specific Permission object instance. For example, a permission instance can specify that only GET verb is allowed for a set of authorized URI’s.
The Apache CXF implementation provides full support for two types of AccessToken that can be used to allow access to protected resources. These are the Bearer Token Type and the MAC Token Type. Additionally, CXF gives us the ability to supply your custom token type.
The Apache CXF implementation provides an out of the box implementation for an Access Token Service that is supposed to capture incoming token requests and handle them properly. This is represented in the class: (“org.apache.cxf.rs.security.oauth2.services.AccessTokenService”)
The AccessTokenService can work with whatever token, created by a given data provider.
The following section provides more information on how CXF may help with supporting Bearer and MAC tokens.
1.2.1. Bearer Token
The Bearer Token Type is the default if no specific access token type is specified. In this case, an AccessToken is being generated and send back to the client. During the communication phase, whoever will bring the bearer token with the request, will be granted an access on a requested protected resource (of course if the token permits that). If the token is deemed valid by the authorization server, then no further questions are asked.
Bearer token validators could be registered on the server side to validate the incoming bearer access token. If no validators are registered, then the CustomOAuthDataProvider will also be asked.
1.2.2. MAC Token
CXF also supports MAC Tokens, as specified in the latest MAC Access Authentication.
Similar to the HTTP Basic access authentication scheme, the MAC scheme utilizes a set of client credentials which include an identifier and key. However, in contrast with the Basic scheme, the key is never included in authenticated requests but is used to calculate the request MAC value which is included instead.
With the Mac and sign_type, the access token is generated and kept as secret, and the encrypted secret is sent back as Access Token. It will become a secret key that only the client and the server are aware of, and no one else can decrypt it, simply because the original token that was used to generate this key is unknown to any suspicious application.
1.2.3. Custom Token
Developer is free to provide a customized implementation for the token concept. One of the main drawbacks of this approach is that you will have to enforce your clients to adhere to a non-standard way of communication.
2- Communication Phase
Following the Handshaking Phase, the Communication Phase starts to take control. Only at this stage the client becomes in a position to request access for a protected resource.
Once the client have been authenticated and got the access token, you can provide the access token to access the protected resources.
Resources are shielded by a filter that verifies the validity of the AccessToken prior to handing the client access to a protected resource.
CXF provides an out of the box filter implementation that does all the work for us. This is the “org.apache.cxf.rs.security.oauth2.filters.OAuthRequestFilter”.
in the next post, I will be presenting the detailed flow of a typical Handshaking scenario, to illustrate the concept in more clarity…..