0

I'm trying to learn more about authentication in microservices using OAuth2.

I've been reading about OAuth2, and while I understand the basics, I have great difficulty understanding how everything works together.

Let's start with an example:

I have a website, which is built on two microservices:

  • auth service: basically an auth2 service that uses resource-owner based password authentication.
  • album: once a user is authenticated, he can create photo albums and share it with other users of the site.
  • website has a "remember me for 30 days" option during login.
  • user should be able to see from which devices and locations he is logged in, and able to terminate them (in case of unauthorised logins). This is similar to functionality that FaceBook and DropBox provide.

Let's start with the authentication app, a typical auth2 response looks like this:

{"refresh_token": "aEMpqJsg6aotX9HaeVnFqqRBaQn7Bo", "access_token": "aSAX21mzmYRnizwhn1ltFZWDsIbif4", "expires_in": 36000, "token_type": "Bearer", "scope": "read write"}

The login-button of my website just does an OAuth2 request my auth service, and receives the response above.Now, what do I do with this information in order to use this? Do I just store this JSON response in a cookie? I need some form of persistence, in order to use this token for subsequent requests.

Next question: Can I just create a token which expires in 30 days, or is this considered a bad practice? If yes, how can I mitigate this without losing this functionality?

Now to the next part: My album service needs to know who the user is. I assume that the API gateway has the responsibility of making sure the token is correct, and also include the user-id in the request? What if the album needs additional information about the user? Should it just contact the auth app for this?

I tried to find the answers to these questions myself, but it's very hard to find actual good information on this. Most of the stuff I found on the net just gave me vague answers, like "read the oauth2 specs" or "use JWT". While I realise a good understanding of oauth2 is necessary, it would be helpful to me if got some explanation by someone who has actual experience in building something like this. (Book recommendations are also welcome).

3

First of all, determine if your services are confidential or not.

Clients capable of maintaining the confidentiality of their credentials (e.g., client implemented on a secure server with restricted access to the client credentials), or capable of secure client authentication using other means.

So, for example Angular Application or Mobile Application are usually not confidential, but backend services are.

If your service is confidential, you can securely store refresh token for a quite a long time (like 30 days). The full flow would be:

  1. Register a client on Authorization server
  2. Securely store client_id and client_secret on your service

After that you can authenticate users:

  1. Authenticate a user
  2. Get access and refresh tokens
  3. Store refresh token securely
  4. When accesstoken is expired, get a new one with refresh token

In that case you have short-lived access tokens and long-lived refresh tokens.

Access tokens that are valid for 30 days is a bad practice, they are usually issued not more than for 8-12 hours.

If your service is not confidential, you can think about using some edge service or reverse proxy that will handle securely storing issues.

Regarding getting access to user information I will recommend to use OpenID Connect that is actually better suited for authentication purposes. OpenID Connect is an authentication protocols that is built on top of OAuth2. Simplified it adds user identity API to the OAuth.

OpenID Connect adds an additional token to the Authorization server response( JWT ID Token) with minimal user information and specified /userinfo endpoint where the service can get additional user information.

To summarize the recommendations:

  1. Use OpenID Connect for authentication
  2. Use OAuth for service-to-service communications
  3. Securely store client credentials andrefresh tokens
  4. Use short-lived access tokens and long-lived refresh tokens
-1

I really like JWT over OAuth2 because JWT is designed for Authentication and Authorization. OAuth2 is just Authorization.

Ignoring that, the both typical are passed to services the same way using headers, e.g:

POST https://your.website.com/api HTTP/1.1
//Other Header informaiton
Authorization: Bearer <Token>

The server will read the Token and compare it to what it has on file and allow/deny based on that. If you need more information on Architecting a Secure Web Service, I'd suggest a Programmers.SE, for specific coding questions Stackoveflow.SE.

Edit: Answers you other questions.

Typically Tokens are stored in Cookies with the Secure Flag (only HTTPS), but you still need to be careful of things like CSRF.

I suggest reading up on https://stormpath.com/blog/. The stormpath team has a lot of good information around all you questions, and even youtube videos which more in-depth discussion and demos. I have never used their services, but I learned a lot from them. They mainly focus on JWT, but also discuss and work with OAuth2.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.