Construction of authorization server using Authlete and communication from OAuth client (Web application)

A memo when using the cloud service Authlete to quickly build an OAuth server.

Authlete is a cloud service for building OAuth2.0 server and OpenID provider. To build a server that supports OAuth 2.0 and OpenID Connect with Honki, it is a matter of course, but by delegating the Mendokusai processing to Authlete, you can easily build an authorization server.

Prerequisites

For the sake of brevity, we will assume that you have some knowledge of OAuth / OpenID Connect. You know about the processing sequence of Authorization Code Grant Flow.

environment

Mac OS X 10.12.6 (macOS Sierra) Apache Maven 3.2.3 Java version: 1.8.0_25 git version 2.11.0 (Apple Git-81)

I'm doing it with, but if maven and git work, I think that anything including the OS is OK

In addition, the characters such as various servers are as follows:

Server name	Use	URL
java-oauth-server	A server that manages authorization information for each user ID. Called an authorization server	http://oauth.example.com:8080/
java-resource-server	A server with data and functions for each user ID. Called a resource server	http://resource.example.com:8081/
java-oauth-client	Web application that uses the resources of the resource server	http://client.example.com:8082/

In this environment, each server is going to be started locally, so please resolve the name to 127.0.0.1 with / etc / hosts etc. as appropriate. Of course, you can give it to any place such as EC2 on AWS.

Rough flow

The general flow is as follows.

Sign up for Authlete
Authorization server registration / client registration
Construction of authorization server and resource server
Communication from the web application

Operation on the Authlete management screen

Sign-up and registration / creation of authorization server information

First, sign up to use Authlete. Sign up from the right shoulder of https://www.authlete.com/.

On the next screen, enter your ID / password / address as shown below.

When sign-up is complete, the top page will be displayed.

It seems that the account has been created and one authorization server (Service 385xxxxxxxx) has already been created.

The API key and API secret are displayed, but since they will be used later when building the authorization server and resource server,

API key	API secret
385xxxxxxxx	NeE89hxxxxxxxxxxxxxxxxxxx

Make a note of it.

By the way, the next login will be https://so.authlete.com/ Log in with your Cocokara ID / password.

Client registration / creation

If you access the URL of "Client App Developer Console" in the above capture, you will see a login screen for client developers, which is different from the above. This is the management screen of the OAuth client, and you can log in with the above API key (385xxxxxxxx) and API secret (NeE89hxxxxxxxxxxxxxxxxxxxx).

When you log in, the client name (Client 4455xxxx) is displayed as above, and the client ID and client secret of that client are displayed. Make a note of these as they will be used later when building an OAuth client or web application.

Client ID	Client secret
4455xxxx	FZlETE9xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

Organize

Well, once organized so far,

Login account to Authlete
"API key" and "API secret" to start the authorization server and resource server with Authlete
"Client ID" and "Client Secret" for building an OAuth client (Web application) registered in the above authorization server

Has been paid out. When you create an account for Authlete, one authorization server (Service 385xxxxxxxx) is created, and one client (Client 4455xxxxx) associated with it seems to be created automatically.

Building authorization server and resource server

Next, build an authorization server that authorizes the OAuth client to access user information, and a resource server that receives requests from the OAuth client and executes processing according to the authority.

In this construction, I will use the following code provided by Authlete.

Authorization server: java-oauth-server
Resource server: java-resource-server

To build, just drop the above code from GitHub and write the API key and API secret that was issued when you signed up to the configuration file.

Building an authorization server

Build an authorization server. All you have to do is clone the repository and set the API key and API secret in the configuration file (authlete.properties).

$ git clone https://github.com/authlete/java-oauth-server.git
$ cd java-oauth-server
$ cat authlete.properties
service.api_key =385xxxxxxxx ← Please change to the correct API key
service.api_secret =NeE89hxxxxxxxxxxxxxxxxxxx ← Please change to the correct API secret
$ mvn clean jetty:run

Building a resource server

Next, build a resource server. All you have to do is clone the repository and set the API key and API secret in the configuration file (authlete.properties). It's the same work as the authorization server.

$ git clone https://github.com/authlete/java-resource-server.git
$ cd java-resource-server/
$ cat authlete.properties
service.api_key =385xxxxxxxx ← Please change to the correct API key
service.api_secret =NeE89hxxxxxxxxxxxxxxxxxxx ← Please change to the correct API secret
$ mvn clean jetty:run

By the way, the resource server is

curl http://resource.example.com:8081/api/country/JP -H "Authorization: Bearer xxxxxxxxxxx" -G

If you request Authorization with an access token, if the access token is correct,

{
  "name": "Japan",
  "alpha2": "JP",
  "alpha3": "JPN",
  "numeric": 392,
  "currency": "JPY"
}

It is made to return a response like.

This completes the construction of the authorization server and resource server.

Communication from web applications

Next, communicate from the Web application. The URL of the web application is http://client.example.com:8082/RedirectServlet Suppose that Try to redirect to the same Servlet http://client.example.com:8082/RedirectServlet after getting the authorization code.

By the way, the processing sequence of Authorization Code Grant Flow is as follows. Authlete issues an authorization code when requested by the authorization server, issues an access token based on the authorization code, and when the resource server receives the access token from the Web application, is the access token correct? It will tell you who the token is associated with, and so on.

Redirect destination registration

Register the redirect destination URI of this web application in Authlete. Open the Client App Developer Console and click the edit button at the bottom.

After that, there is a setting called redirect URI on the authorization tab, so write "http://client.example.com:8082/RedirectServlet" and click the update button to complete.

It has been registered.

Building a web application

The web application is as shown in the sequence diagram above.

Click a link such as Login with ○○ on the Web screen (the link destination will be RidirectServlet).
Screen display of authorization server (redirect from Servlet with 302)
User executes authentication / authorization operation on authorization server
After the authorization operation, the authorization code is generated and the authorization server redirects to the specified URI (redirected to the original Servlet with 302 and returned).
When you come back, access the authorization server with the authorization code and get an access token.
Use the access token to call the resource server API (such as inquiring about data acquisition)
Get results

What kind of processing flow is it, but since I created such a Servlet, I will use that project as it is.

Web application: java-oauth-client

After dropping, change the values of client_id and client_secret in the configuration file (settings1.properties) to client ID and client secret as shown below.

$ git clone https://github.com/masatomix/java-oauth-client.git
$ cd java-oauth-client/
$ git checkout -t origin/feature/forQiita
$ cat src/main/resources/settings1.properties
client_id =4455xxxx ← Please change to the correct client ID
client_secret =FZlETE9xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx ← Please change to the correct client secret
$ mvn clean jetty:run

Try to communicate.

When you access http://client.example.com:8082/, the link "Authorization processing with OAuth server using Authlete." Is displayed. Click it.

Then, the authorization server will give the following "This web application wants to access your information, but authorize it?", So after thinking about it, the user will say "Who am I"? Enter your Password and press Authorize to authorize access.

Since the authorization server and resource server provided by Authlete are coded with dummy user authentication,

Login ID	Password
john	john

Please authenticate and authorize with the account.

When the web application is authorized, an authorization code is issued to the web application and redirected back to the original Servlet with 302. Furthermore, the Servlet asks the authorization server to obtain an access token, and obtains the access token from the authorization server. Once you get the access token from the authorization server, the Servlet will be in the HTTP header

Authorization:Bearer uU3Xml7rdxxxxxxxxx ← Access token

To request the resource server to acquire data. After having Authlete verify the validity of the token, the resource server runs the logic and returns the data to the Servlet.

It is OK if a series of these processes are performed and the data is finally returned to the screen.

Thank you for your hard work.

In the process inside the Servlet

Display of id_token (so-called OpenID Connect id_token) returned with access token from token_endpoint API to get token
Divide the id_token into Header, Payload (main body), Signature (signature) according to JWT specifications, Base64 decode and display
Check the signature method in the JWT header and verify the signature to check that it has not been tampered with. (By default, Authlete seems to be signed with HS256 in the client secret, so I'm verifying with that)
If necessary, such as when signing with RS256, access the endpoint (jwks_uri) where JWK (JSON Web Key) is published, obtain the public key, and verify the signature with the public key.
Data acquisition to userinfo_endpoint based on OpenID Connect specifications

I wrote various things such as, but if you are interested, please refer to the code.

By the way, please note that there are various security-related considerations such as CSRF measures when actually building the production.