We are currently trying to figure out a way to implement token based authentication and authorisation with Facebook Connect combined with maybe JWT within the micro service architecture.

System Context

  1. SPA Application - A simple single page application which will be hosted somewhere on a CDN.

  2. Microservices - Every single service will be written in accordance to the microservice architecture. One of those services will be the user service which will handle all user related stuff (e.g tokens, user information)


  1. The user should be able to authenticate against our services with a Facebook access token. In the future we might also integrate further parts of the Facebook graph API in which case we would also need the access token.

  2. There should be a mechanism to authenticate and authorise a user on any microservice. Multiple services will be called in sequence which would that we support some type of chaining (e.g OAuth on-behalf-of).

Some Ideas regarding a possible flow

  1. Facebook Connect SDK - Authenticate against Facebook which would later also allow possible calls to the graph api.

  2. User Access Token - The user retrieves a short-lived access token from Facebook and sends it to our user service.

  3. User Service Verification - The user service verifies the access token against Facebook.

  4. User Service Verification Succeeds - The User service requests a long-lived access token from default short-lived access token which Facebook generated. This token should be valid for 60 days.

  5. User Service DB Entry - The Hash of the long-lived access token is stored in the database. I don’t see any particular reason why I would need in absence of the user the token and thus would avoid the potential risk of a compromised access tokens. Didn't put in much thought into the database schema but I was thinking something about three tables Account, Login and Claim to store the login specific data. While each relationship would be 1:n. The hash would be stored on in the Login table for the Facebook provider.

  6. User Service & JWT - The user service creates a new JWT from all the claims related to this particular Account. There might also be some additional Logins / Claims from other providers which won't be part of what Facebook will deliver (e.g administrator Login with the corresponding claims). Furthermore also add the long-lived Facebook access token to the JWT.

  7. Store JWT - Send the newly created JWT back to the client and store it within the local or session storage. At this point the already existing access token from Facebook in the cookie could be deleted I assume?

  8. Facebook SDK - Somehow tell the Facebook SDK that it should from now check the JWT in the local storage regarding the Facebook access token. If any of the other services receives a request the following would happen JWT is received by some random service. The JWT token which contains the Facebook Access Token would be veryfied via public key cryptography which would avoid an additional request to the user service. If the JWT token has expired the whole chain of services fails and the user is redirected to the facebook login page from the SPA and the whole flow would start again.

Improvements & Feedback

I am almost certain that I overlooked some maybe key things and that's why I would appreciate any help regarding possible improvements. I would also appreciate you're feedback if this could be done somehow easier and in a more secure way. For the most parts of the implementation we would of course rely on state-of the art libraries and wouldn't write anything by ourself.


You must log in to answer this question.

Browse other questions tagged .