Page tree
Skip to end of metadata
Go to start of metadata

Simon Mofatt 

OAuth2 microservices

Stateless OAuth2 microservices

very lightweight authentication microservice : tiny memory footprint.  (JSON configuration (immutable configuration), Java application based on OSGi, no JEE container, it uses Jetty)

Containerized (Docker, Kubernetes, CloudFoundry)

Metrics (Dropwizard, Prometheus)

3 new microservices : tokens creation, tokens validation, tokens exchange

Why Microservices ?  => architecture flexiblitly, scaling and load management.

Only a few ones are actually deploying microservices.

Hybrid architecture : some microservices mixed with "old" applications

Authn service : create OAuth2 stateless access tokens. Only credentials_flow because the target is machine-to-machine . Possible to use different storage for client credentials store ( FR Directory Services, Active Directory, MongoDB Cassandra)

To communicate between them, each microservice sends an access_token. When it is received then it call the token validation microservice.

Token validation : only validate the acces_token : parse, verify signature, checking expiry, scopes, .... It is protected itself by an access_token. For policy : embedded (declared in JSON files) or it can ask AM for authorizations (based on policy decisions)

How to invalidate a stateless token before it is expired ? => in AM there is a blacklist to handle this.  This does not exist yet in microservices. But the lifetime of access_tokens is very short, so that reduces the window.

Token exchange :   in AM this is STS. Here it exchanges 1 access_token with 1 other access_token with another set of scopes. It is protected itself by an access_token. Useful when the second token has to be used whenin behalf of the first one.

Difference with IG ? IG can't deliver tokens, it will only validate them to protected API.

  • No labels