CODEWITHSUNDEEP
authenticationoauth-2.0oauthjwt
user890234
user890234

Reputation: 995

bearer JWT token client authentication and access token issued by authorization server

authorization server issues an access token with issuer details which are exposed in well-known api of that server. this server uses client authentication JWT token with clients configured , these JWT tokens are sent as a part of request from clients to authorization server and having one of the claim audience of authorization server with URL and port.

Now, the question is should well-known api have the same issuer URL(access token) details as audience in (JWT), or the JWT audience can be different URL with port of authorization server.

payload of client authentication JWT

{
"aud":"https://server:port"
}

payload of access token JWT

{
"iss":"https://server/address/abc"
}

Upvotes: 0

Views: 795

Answers (1)

Gary Archer
Gary Archer

Reputation: 29198

CLIENT ASSERTIONS

The rules for using JWTs as client assertions are explained in RFC7523. This is different to JWT access tokens issued by the authorization server. A typical header and payload looks like this:

{
  "kid": "1",
  "alg": "RS256"
}
{
  "sub": "my-client",
  "iss": "my-client",
  "aud": "urn:mycompany.com",
  "jti": "7eb87efb-2094-ecf0-531a-357c1d570582",
  "scope": "read",
  "iat": 1651070751703,
  "exp": 1651070811703
}

The client application has its own private key and uses a JWT library to issue the JWT. The corresponding public key used by the authorization server to verify client assertions can be pasted into the OAuth client registered in the authorization server.

Alternatively an external JWKS URI can be configured against the OAuth client. The party providing the client then provides the JWKS endpoint.

ISSUER

This must always the client application when using client assertions, as explained in section 3.1 of the above spec. In my example this is the value my-client.

AUDIENCE

The aud claim must represent the authorization server, as explained in point 3.3 of the above spec.

This can be the URL of the token endpoint, or the issuer URL or your issuer identifier, eg urn:mycompany.com.

The most cutting edge behaviour is described in the FAPI 2.0 profile, for higher security apps. Point 20 says that the issuer identifier should be accepted in the aud claim. This is a requirement in order for the authorization server to be considered FAPI 2.0 compliant - not all auth servers are.

ANSWER TO YOUR QUESTION

This is the standards based way to do it:

  1. In your app's code, set iss to a value representing your client application, as in my example.

  2. In your app's code, set aud to the issuer identifier of the auth server.

  3. In the auth server, register an OAuth client. Configure the public key for the keypair used to create the assertion there. Either by value (pasting it in) or hy reference (JWKS URI). If there is a setting for issuer, configure the value of the client, which is my-client in the above example.

So the behaviour you describe seems correct and expected. Test with invalid values, and ensure that you get a 401 error.

Upvotes: 0

Related Questions