Debugging The interface between Resource Server and Authorization Server (oauth 2.0. validation access token)

Question

There are two spring-boot apps.

1. client
2. resource-sever there is dev okta account that is used as auth server

(those 2 apps are standard Spring Boot client -> resource-server, almost out of the box with okta setup for them, should not be problem there)

client - securely sends messages to--> secure-sever (passing the access token in the header as prove that it's authorized to call it and get data back)

(it works as expected)

But I am trying to figure out what's going on between all them, traffic wise

I'm trying to spot that moment when resource-server checks the token it got from the client that got it from the auth server.

Here is a sequence diagram of standard oauth 2.0 flow and that part that I want to debug (arrow)

auth server

And there is a communications between client, resource-sever:

There seems I can not confirm that Resource Server (from the right) does any token validation with the auth-server (okta)..?

Question: is why? From my understanding it is supposed to validate it (somehow).

I was expecting to see a call from resource-server to auth-server (otka) with the token-validation-request (ETF RFC 7662 in October 2015) like this:

How to validate an OAuth 2.0 access token for a resource server?

I was expecting, lets say, tat for every client call, resource server would check if that token the client passes is valid. Yet I do not see any calls from resource service to okta that would use the token in its requests to okta.

Bautista

Answer 1

This comes down to the difference between JWTs and opaque tokens.

It looks like your application is using JWTs, based on the calls I'm seeing to /keys.

When using JWT authentication the resource server will query the jwks_url (in this case /keys) on startup to retrieve a set of public keys that it can use to validate the JWT-encoded bearer tokens.

Then, when the resource server receives a bearer token in a request from the client it will validate its signature against a public key obtained from the jwks_url endpoint.

This means the resource server doesn't have to query the authorization server on every request.
You can read more about this process in the OAuth 2.0 Resource Server JWT section of the Spring Security reference documentation.

The question that you linked to refers to opaque tokens.
In this setup, the resource server must call the authorization server introspection endpoint to validate the token every time. You can read more about this process in the OAuth 2.0 Resource Server Opaque Token section of the Spring Security reference documentation.

Deracinate

It should be mentioned though, that this method can't validate if a token has been revoked after it had been issued – Janettjanetta

There's still periodic call to/keys 🔑 endpoint so if token is reinvoked, I guess it keep the keys up to date. Not sure what happens in hr moment if New reinvoked tokens, I guess extra /keys call will be made..? – Bautista