Manually adding a JWK Set in AM, where does it appear when you do an HTTP GET for the URL for "http://..../connect/jwk_uri" is called?

Hi, I am running an evaluation of ForgeRock AM and trying to understand the following :

  • I created a new realm ( named subrealm )
  • I added a trusted JWT issuer agent in this subrealm
  • In this trusted JWT issuer agent, I added a JWK Set that I have created myself, then clicked on “Save changes” for the trusted JWT issuer agent.

When I then do an HTTP query the the corresponding “connect/jwk_uri” URI, shouldn’t the keyset that I added be in the response ?

I have tried :

… and a few other URLs, but they return 5 other keys in the set that I know nothing about where they came from, and where they are configured in the AM admin console ??

Hi and welcome to the community,

Could you please elaborate on why you need to publish a public key.
The Trusted JWT Issuer is there to verify signatures in incoming JWTs as described in the documentation:

1 Like

Hi @gery.ducatel ,

I see. So I think I have misunderstood the purpose of that in combination with what I am trying to do with a SpringBoot OAuth2 Resource Server.

Basically :

  • I am writing a simple / test SpringBoot app as an OAuth2 Resource Server trying to integrate it with ForgeRock AM as an OAuth2 Authorisation Server. This resource server basically exposes REST APIs to be consumed by OAuth2 client applications. Basically Machine-to-Machine interaction, no human / person involvement.

  • I have another test SpringBoot app, an OAuth2 client app. This client app has both the private and public key in JWK ( stored locally for now just for testing purposes ) … and the public key of that JWK from the client app I then saved into ForgeRock AM’s trusted issuer agent’s “JWK Set”.

  • Back to the SpringBoot app OAuth2 Resource server, I am configuring the jwks_uri property of the resource server to that of ForgeRock AM’s publicly published jwks_uri, as described here :

  • Back to the client app, the OAuth2 client app creates a signed JWT ( therefore it needs the private key ) and make an API call to the OAuth2 Resource server with the signed JWT as the bearer token in the HTTP Authorization request header.

  • When the SpringBoot app OAuth2 resource server receives the HTTP request, it is trying to validate the signed JWT bearer token. It does this by calling ForgeRock AM’s connect/jwk_uri … which I have configured as a property value in the resource server as indicated above in that link to SpringBoot Security’s public documentation URL.

  • From debugging SpringBoot’s OAuth2 resource server code ( SpringBoot security’s code, not mine ), it looks for the “kid” in the signed JWT with the “kids” it got from ForgeRock AM’s connect/jwk_uri. Seeing it is not there, SpringBoot’s OAuth2 resource server code ( again SpringBoot security’s code, not mine ), then decides to reject the HTTP request from the client app with an HTTP 401.

  • Previously, the test SpringBoot app OAuth2 resource server have a copy of the public key as documented here in SpringBoot Security public documentation:

  • With the public key locally available to the SpringBoot app OAuth2 resource server, the REST HTTP API call from SpringBoot app OAuth2 client works and the the SpringBoot app OAuth2 resource server responds with an HTTP 200. So I am trying to progress from that test setup to have the keys retrieved remotely.

Maybe I am getting confused with interpreting the documentation from SpringBoot Security with the documentation from ForgeRock AM and how to integrate them all together, and maybe I am misunderstanding the architecture alltogether.

Anyway, I will change the test setup so that the SpringBoot OAuth2 client app will request authorisation from ForgeRock AM, and then the client app sends the received access token to the SpringBoot OAuth2 resource server.

Hi @gery.ducatel ,

But if that’s the case, how do I configure everything so that I can have JWT stateless authentication ( Again probably a confusion on my part ) ?

From the following links :

The above 2 links show that the resource server does not even consult / query the authorisation server.

But the link you showed me for ForgeRock AM’s “JWT profile for OAuth2 authorisation grant” shows that the resource server still need to query ForgeRock AM to validate the access token ?

Sorry it is taking time to respond.
You should share what flow you are trying to execute to make things a bit easier.
The OAuth 2.0 client should get a token from AM, and then present it to the resource server. The token is going to be signed by AM, not the client.
The client could use certificates to authenticate to AM, as per the documentation: