Cannot access the management API

[frenetisch-applaudierend]

I'm trying to access the management api from a .NET sample application adapted from IdentityModel.OidcClient.Samples.

Logto is running locally in docker, on http://localhost:3001. I have setup an initial admin user (alice) and added a native application.

Using the following configuration of OidcClient I can get an identity token as well as an access token:

new OidcClientOptions
{
    Authority = "http://localhost:3001/oidc",
    ClientId = "MkXHHYWKKzKCXxfBH6DpU",
    Resource = new[] { "https://api.logto.io" },
    RedirectUri = "http://127.0.0.1:3333",
    Scope = "openid profile api",
    FilterClaims = false,
    Browser = browser, // this is OidcClient specific I think, to call the system browser for login
}

The decoded identity token JWT looks like this:

Header:
{
  "alg": "RS256",
  "typ": "JWT",
  "kid": "ujS9GMr4khjFOQDjjMYvvbZ0Sdt1ewR2sPir2ybeNZQ"
}

Payload:
{
  "sub": "qVxQkj2IetY8",
  "username": "alice",
  "name": null,
  "avatar": null,
  "role_names": [
    "admin"
  ],
  "nonce": "fHJ_HwdQgU2leH267pSQvw",
  "at_hash": "N3tYvaaXnwtVKfOW_HhKKA",
  "aud": "MkXHHYWKKzKCXxfBH6DpU",
  "exp": 1663669355,
  "iat": 1663665755,
  "iss": "http://localhost:3001/oidc"
}

The access token does not seem to be a JWT.

I can pass the access token to /oidc/me to get user information.

When passing the access token to /api/users however I get the following error (401):

{
  "message": "Unauthorized. Please check credentials and its scope.",
  "code": "auth.unauthorized",
  "data": {
    "code": "ERR_JWS_INVALID",
    "name": "JWSInvalid"
  }
}

If I pass the identity token the error message is different (401):

{
  "message": "Unauthorized. Please check credentials and its scope.",
  "code": "auth.unauthorized",
  "data": {
    "code": "ERR_JWT_CLAIM_VALIDATION_FAILED",
    "name": "JWTClaimValidationFailed",
    "claim": "aud",
    "reason": "check_failed"
  }
}

The documentation mentions that the aud must be "https://api.logto.io", but I don't know how to get such a token. The aud seems always to match the application id, and using "https://api.logto.io" as application id does also not work, since there is no such app.

Any help to what I'm doing wrong is much appreciated!

[simeng-li]

@frenetisch-applaudierend did your .NET application handles the OIDC interaction internally?

(Since we do not have a .Net SDK yet, I assume the sign-in flow is handled internally by the IdentityModal you pasted here.)

1. The access_token you received is not in a JWT format. That is because the token has no API resource audience. The code can be used to access the /oidc/me API only according to the OIDC protocol.
2. Each JWT formatted access token is granted exclusively for the target API resource being requested. In order to claim that token e.g access token for Logto management API "https://api.logto.io/", you will have to pass in that as a resource param in the token request API.

Like our React SDK.

This is the same as you set for the OidcClientOptions so far.

However when trying to retrieve a specific access token for some API. You will have to let the Logto server know which API resource's access token you are asking for.

You will only get the default access_token from the initial sign-in authorization flow. You will have to ask for an access_token exclusively for the API using the refresh token returned the first time.

That might be the gap.

It would be helpful if you could get the exact /auth/token request body. We can check if the resource param is present.

Let me know if these make any sense to you.

[simeng-li]

https://github.com/IdentityModel/IdentityModel.OidcClient/blob/main/src/OidcClient/ResponseProcessor.cs#L179

This is where I can locate that the auth code is redeemed and exchanged for a token. As you can see no resource is being passed. So the default access token you received is not in JWT format, also not intent for any custom API use.

Looks like the IdentityModel allows you to pass in additional params to the refreshToken request just like we did in our SDKs:

https://github.com/IdentityModel/IdentityModel.OidcClient/blob/06fcf23a5fbdbcf5b8269ef28f4386e09d6e9b69/src/OidcClient/OidcClient.cs#L319

Once you first login and get the refresh token from the token response. Can you try to call this RefreshTokenAsync with additional back-channel params: sth like:

var refreshResult = await _oidcClient.RefreshTokenAsync(currentRefreshToken, { resource: "https://api.logto.io"} );

The will ask Logto to issue a new access token exclusively for the usage of the management API.

See how it goes.

[frenetisch-applaudierend]

Thanks for the quick reply!

This is definitely going in the right direction, however I'm still stuck. I found that I can pass the back channel params also to the LoginAsync method which in turn passes them to the redeeming call. Now I get the following error:

Error redeeming code: invalid_target / resource indicator is missing, or unknown

The resource is set in the HTTP request going out, according to the debugger (sorry I cannot get the body right now, as Charles has trouble with localhost, and logto seems to require HTTPS with anything else which opens a whole other can of worms 😬) :

> string.Join(' ', request.Parameters)
"[resource, https://api.logto.io] [grant_type, authorization_code] [code, o0eLjvUtXuuRKB2xlP6RxG4GgvvkzgEr3IQseVvAtgY] [redirect_uri, http://127.0.0.1:3333] [code_verifier, chWuLL-cGnSv_cdoi8ggX-__5LdRNbXs4mEe6gx47e0] [client_id, MkXHHYWKKzKCXxfBH6DpU]"

I will try also with the refresh token and see if that makes a difference.

[frenetisch-applaudierend]

No luck with the refresh token either, because it seems that no refresh token is returned (or the library does not expose it to me).

[simeng-li]

Interesting this works well for me with the oidc/token request body like this:

One more thing to check, make sure the resource is passed properly at the very beginning auth request. Can you check the signIn URI being generated oidc/auth? to see if the resource is present in the query params?

Like this:

Also, looks like IdentityModal Client has a refreshTokenAsync method?

RefreshTokenAsync

[frenetisch-applaudierend]

Sorry for the late reply.

Here is the current login flow as I was able to piece it together (line breaks for readability):

1. Client authenticates

http://localhost:3001/oidc/auth?
    response_type=code&
    nonce=LznJwZDmIy5IJPZNZJezjQ&
    state=-Gi1-WRZEE1atNBAW0VUbg&
    code_challenge=guOH81KWCg4LRtz9Y2-C4I2J2fvLh4R82E62E5K9CoY&
    code_challenge_method=S256&
    client_id=JQHaU0IJt5Jvfj4RwDRZM&
    scope=openid%20profile%20api&
    resource=https%3A%2F%2Fapi.logto.io&
    redirect_uri=http%3A%2F%2F127.0.0.1%3A3333

2. Logto redirects to client

http://127.0.0.1:3333?
    code=JkSvJHPs9wGs3zpoip_u6cRfJ2udkTzl2kW46UgH9A_&
    state=-Gi1-WRZEE1atNBAW0VUbg&
    iss=http%3A%2F%2Flocalhost%3A3001%2Foidc

3. Client redeems code

http://localhost:3001/oidc/token

grant_type=authorization_code&
code=JkSvJHPs9wGs3zpoip_u6cRfJ2udkTzl2kW46UgH9A_&
redirect_uri=http%3A%2F%2F127.0.0.1%3A3333&
code_verifier=IQspRv-UX5Ly1an1VL7SbaxSsJFkULUM0_3ISUYwnaI&
client_id=JQHaU0IJt5Jvfj4RwDRZM

4. Logto returns id and access tokens

{
  "access_token":"lIeJHzvsqfn04qn8NqluOTuZIK3FrvLTZ2QSEVZDafJ",
  "expires_in":3600,
  "id_token":"<see below>",
  "scope":"openid profile",
  "token_type":"Bearer"
}

id_token:
eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCIsImtpZCI6IkI5aGNMdzJVbTVMM3ZwSUh3YnE0LUpwVVF3OF9ISzdINFdaVzBpMloySjAifQ.eyJzdWIiOiJFZ3YxM3B1NjlObEwiLCJ1c2VybmFtZSI6ImFsaWNlIiwibmFtZSI6bnVsbCwiYXZhdGFyIjpudWxsLCJyb2xlX25hbWVzIjpbImFkbWluIl0sIm5vbmNlIjoiTHpuSndaRG1JeTVJSlBaTlpKZXpqUSIsImF0X2hhc2giOiJGRWZjYVR2eHVYaFV4cnFqWTFKWjlRIiwiYXVkIjoiSlFIYVUwSUp0NUp2Zmo0UndEUlpNIiwiZXhwIjoxNjY0MTc3NzQwLCJpYXQiOjE2NjQxNzQxNDAsImlzcyI6Imh0dHA6Ly9sb2NhbGhvc3Q6MzAwMS9vaWRjIn0.qd9NpFrE0R_lBBfJyngDMzr5JZzZbpthPzOwi5NFkfzwg11PFEj7sV3wU78fUfXXZM8tMZcBQpoH5nTlOJbgcOSftdsCBJI5VIlvtmPHG3dc4WXFlRhpXV_jnFYqizxdUijdv8vpaoE4outOlfO3gAFXzsc2sdiEYzDeJSGU9PIuEvsJfGmZ88CjaEu3NRi2CgUMmwfNXxOGfEwd-_aXBHiG8Tns1nA-z_xPv9zkdkmQ8DzrxdjsMIGP1zhN9x5sxs5IKGVn8BNhloVP2j-DVw2SEPGLuV3cDXKdtG9nnjmon0laF7gvoXPyIniXUa5ecmly3ZrNcy4JpjPuz_vM9kycgAIh1gjGT_eyn42AiCK81i0fJ_kniW9fpeL1v1nQC6c9xyxA-ah_nohBHmTE6ohPl-W_Nk2pp6SX63YchZLEkymlcIvhLb6vDoVJzM7LMUB54_Y59zvSR1qQEJNsK-T3QyIym9FoO50ddFqiAkKiGBGIcFPYkDb0B42---gYNEt5MngLS0_9-GcFkj7U-sKLVfTpg0MWOIzMgj4FosMp599o7B9lIXYo1D27hDBLEMGqmXulUgBPMGV_fXWt13V5EJljW1QcHoutpKw2pN78EMNqH6ulCwIx07nzkQOzNRzdgK7OZ7Na6Z6yny-oAftkhOAbu02VfeDrj1jq98c

Note that there seems to be no refresh_token which is what I meant by "it seems that no refresh token is returned (or the library does not expose it to me)".

I notice that the resource is not present in the token request. But it was in the initial auth request.

[frenetisch-applaudierend]

Ok, adding the back channel parameter to the login request passes it along to the token request. This gives me an auth token with the correct aud claim, but without scopes. Later the client tries to get user info which fails (presumably because the profile scope is needed for this call).

The auth token emitted however seems to work for accessing the api.

Thank you for your help and your patience. Much appreciated!

[simeng-li]

@frenetisch-applaudierend how does it go?