Separate Auth Server and Resource Server

[edge33]

According to the docs:

The public key should be distributed to any services (for example resource servers) that validate access tokens.

So I though I might be able to separate the auth server and the resource server.

but, can I actually run auth server and resource server on separate machines? I saw the snippet for creating the res server:

$server = new \League\OAuth2\Server\ResourceServer(
    $accessTokenRepository,
    $publicKeyPath
);

it takes in the AccessTokenRepository, In case the Auth and Resource servers run on different machines, I expect Res server not to have access to AccessToken 'storage', since those are located in the domain of the auth server?

Am I missing something, or the resource server and the Auth server need to reside in the same place, or have both access to the same tokenRepository?

[eugene-borovov]

The AuthorizationValidatorInterface implementation on ResourceServer should request AuthServer in isAccessTokenRevoked method. It may be a common database or a remote API call.

[edge33]

Ok then. I though with JWT tokens I might have been able to validate tokens only by having auth server public key, but this is not the case. thank you very much for the clarification ;)

[eugene-borovov]

The token revocation check is performed after the JWT check. You can disable it in isAccessTokenRevoked, always returning false.

[edge33]

Brilliant! thank you :)

[ash-m]

The AuthorizationValidatorInterface implementation on ResourceServer should request AuthServer in isAccessTokenRevoked() method. It may be a common database or a remote API call.

I am not sure if my confusion is possibly from code changes since these comments, but I don't understand how that answers the initial question. I think your suggestion is to implement the AuthorizationValidatorInterface instead of using the ResourceServer, but as far as isAccessTokenRevoked(), that method uses a implementation of an AccessTokenRepository. Implementing it would mean a resource server would have to implement getNewToken(), persistNewAccessToken() and revokeAccessToken().

As far as I can tell, I would not expect a resource server to implement any of those methods.

On another note, is there some reason why you suggest asking the Authorization Server for isAccessTokenRevoked() when it comes to using a JWT? If the signature validates with a public key, then we know that the token has not been tampered with, so the exp claim should be sufficient to check if the token has expired over time and we can cache the jti claim on the resource server as a nonce to prevent replay attacks.

If there is a real reason to proxy the Authorization Server, I would expect the token to be opaque instead of a JWT.