Middleware to enable OpenID Connect claims based authentication against an oidc provider (tested against Okta Preview). Includes middleware for both Express, Restify and socket.io.
This project basically came about as I wanted to make use of Json Web Tokens in a microservers architecture to pass around claims related to identity without constantly querying the OAuth server.
- Minimal configuration, automatic OpenID configuration discovery (/.well-known/openid-configuration)
- Validation of JWTs against the Published Public Keys (jwks_uri) of the OpenID Connect provider
- Only supports RSA (RS256, RS384, RS512) signed JWT tokens at the moment
- OIDC Provider public keys are cached once downloaded until the server restarts, as per the Okta OIDC spec, these change four times per year without warning
- Only basic user information is returned at the moment, need to add the /userinfo extension
- This code is so happy path it's not even funny
Authentication, not Authorisation
The purpose here is to prove to the microservices who you are, not what you can do. Subsequently; you'll need to think about AuthZ, and your implementation is going to be highly dependent on your architecture (each service might have it's own AuthZ? You might not need AuthZ because everyone can do everything if they're authenticated?).
Remember the JWT is just a signed set of claims, by one server, that another server trusts. For example:
"Hi Application Server, I want to access your resources and my username is bob, here is proof i am bob from Okta in the form of a JWT that's signed by Oktas private key"
Your user is visiting a web page which aggregates information from multiple other microservices, each of those microservices however needs to know that you're authenticated, and who you are in order to provide the information back to you.
- Okta as an OpenID Connect provider
- Application: Some web application
- Microservice 1
- Microservice 2
The sequence looks like this:
Note: Security Consideration: If a JWT is going to leave your network; it would be good practice to dereference it first. For example; if NGINX was in front of all of these services, it could handle the referencing of an incoming arbitary token to a JWT, which is then passed to the upstream.
let restify = ;let oidc = ;let server = restify;server;server;server;let auth =oidcServer: ''clientId: 'clientid-here'clientSecret: 'clientsecret-here'callbackURL: ''additionalScopes: 'address';let middleware = auth;// Visiting this url, will redirect you to Okta for OAuth autenticationserver;// This URL is called back from Oktaserver;// Protected resource expects the jwt to prove who they are to be passed// in the query string as id_token=jwthash, not passing jwt here results// in a 401server;server;
let cookieParser = require('cookie-parser'); app.use(cookieParser);
Something people always forget about are web sockets. Using this example; you can have a secure socket.io session too.
So here is your server:
const app = ;const http = ;const io = http;const middleware = auth;io;io;http;
And here is your client:
const socket = ioClient;socket;