CODEWITHSUNDEEP
authenticationoauth-2.0microservicesopenid-connect
Szyszka947
Szyszka947

Reputation: 892

Right way for access token flow between microservices secured with OAuth/OIDC

I have WebSocket server to which authenticated users can connect. They authenticate by passing access token, provided by IdP (OIDC) using authorization_code grant. When user disconnects, I need to call other microservices to store some information. But the other microservices also require authentication, but after this long standing WebSocket connection the received access token is expired (and also I don't know if passing access token between microservices is a good idea).

How to deal with such case? I got some ideas:

  1. Microservices can use client_credentials grant type in communication between them, and provide kind of user identifier as a HTTP request parameter. But it doesn't seem really nice option because it ignores the fact that the user gave permission to access some API, and makes the user unable to revoke this access (without implementing additional mechanisms).
  2. I need to create some kind of auth microservice which will manage refresh tokens, so I can call it from any microservice, it will refresh the token through IdP and return valid access token. But it doesn't seem secure, as I need to store user's refresh tokens.

So, what is the correct approach? (I hope any of these above...)

Upvotes: 1

Views: 48

Answers (2)

Gary Archer
Gary Archer

Reputation: 29291

A websocket server should ensure that the client's access token is still valid before allowing secure data to be exchanged, to follow the spirit of OAuth. More on websocket techniques in this answer.

The client may receive expired responses from the server and needs to handle them by refreshing the access token and retrying the request.

When a user is present you should not use the client credentials grant. Instead the user ID and other claims should remain verifiable for all APIs. To enable this APIs should send access tokens to each other.

To limit access token usage, each API should check for its own required values for these access token fields, which you can design in multiple ways:

  • scope: often represents a business area
  • audience: the identity of the API

In simple deployments, e.g. related microservices, you can usually just forward the original access token. Another option is for a source API to use token exchange to get a restricted privilege user level access token to send to the target API.

Upvotes: 1

Christophe Quintard
Christophe Quintard

Reputation: 2743

It is not because you are using websocket that you must not check the validity of the access token. If the access token is expired, then the user must provide a new one. Either he closes the websocket and opens a new one with the new access token, or better he provides the new access token through the websocket.

The service that receives the request(s) from the user must check the access token. That service makes requests to other services on behalf of the user by passing the access token to the other services. The other services will also verify the token. This is the security-in-depth strategy. It ensures that the user has sufficient permissions even for the deepest service that will be involved.

Upvotes: 1

Related Questions