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?

[JOY]

Same issue with latest docker image: Unauthorized. Please check credentials and its scope

[FernandoGlezR]

Using Logto with ASP.NET Core (MVC) and Access Tokens as JWTs

I faced a similar issue when integrating Logto with an ASP.NET Core MVC application.
My main goal was to expose an API that allows login using the full OIDC flow provided by Logto.

I tested this solution in .NET 8 and .NET 9.

---

Problem

Initially, I tried the official Logto SDK:

• Package: Logto.AspNetCore.Authentication
• Current version: 0.2.0

Inside the configuration, the AddLogtoAuthentication method provides a Resource property.
In theory, this should make Logto issue an access token as a JWT instead of an opaque token.

However, in practice:

• After login, the SDK entered a loop.
• It constantly called Logto’s /oidc/me endpoint to fetch user information.
• The JWT was technically issued at that point, but the flow got stuck.

I tried disabling the property responsible for fetching user info:

builder.Services.AddLogtoAuthentication(options => {
    options.GetClaimsFromUserInfoEndpoint = false;
});

Even though the default is already false, the problem persisted.

---

Solution

Instead of the Logto SDK, I switched to the generic OIDC middleware:

• Package: Microsoft.AspNetCore.Authentication.OpenIdConnect

This means:

• You lose the Logto-specific middleware for refresh tokens.
• But you gain more control and visibility into how the flow actually works.

Here’s the key detail:

• The Resource property exists on OpenIdConnectOptions but is deprecated.
• It does not work when redeeming the authorization code.
• Instead, you must inject the resource parameter into the token request using an event handler.

---

Step-by-Step Implementation

1. Configure Authentication Schemes

builder.Services.AddAuthentication(options =>
{
    options.DefaultScheme = CookieAuthenticationDefaults.AuthenticationScheme;
    options.DefaultChallengeScheme = OpenIdConnectDefaults.AuthenticationScheme;
})
.AddCookie(options =>
{
    options.Cookie.HttpOnly = true;
    options.Cookie.SameSite = SameSiteMode.Lax;
    options.Cookie.SecurePolicy = CookieSecurePolicy.Always;
})
.AddOpenIdConnect(options =>
{
    options.SignInScheme = CookieAuthenticationDefaults.AuthenticationScheme;
    options.Authority = "<logto-endpoint>";   // e.g. https://your-logto-domain/oidc
    options.ClientId = "<app-id>";
    options.ClientSecret = "<app-secret>";
    options.ResponseType = "code";
    options.SaveTokens = true;

    // Request scopes
    options.Scope.Add("openid");
    options.Scope.Add("profile");
    options.Scope.Add("email");
    options.Scope.Add("roles");

    // Inject the `resource` parameter during token exchange
    options.Events = new OpenIdConnectEvents
    {
        OnAuthorizationCodeReceived = async ctx =>
        {
            ctx.TokenEndpointRequest?.Parameters.Add("resource", "<api-resource>");
            await Task.CompletedTask;
        }
    };
});

---

2. Notes on Refresh Tokens

If you need a refresh token:

• In Logto, you must explicitly configure it as mandatory.
• Adding offline_access to scopes was not enough in my tests; the API resource itself must be configured to issue refresh tokens.

---

Result

After making these changes, the access token returned by Logto is a JWT instead of an opaque string.

This lets you validate tokens directly in your API using standard JWT middleware, without relying on the /oidc/me endpoint or token introspection.

---

Debugging Example

You can test this setup and confirm that tokens and claims are being issued correctly by adding a debug endpoint:

app.MapGet("/debug", async (HttpContext ctx) =>
{
    var idToken = await ctx.GetTokenAsync("id_token");
    var accessToken = await ctx.GetTokenAsync("access_token");
    var refreshToken = await ctx.GetTokenAsync("refresh_token");

    var claims = ctx.User.Claims.Select(c => new { c.Type, c.Value });
    var roles = ctx.User.Claims
        .Where(claim => claim.Type == ClaimTypes.Role)
        .Select(claim => claim.Value)
        .ToList();

    return Results.Json(new
    {
        IdToken = idToken,
        AccessToken = accessToken,
        RefreshToken = refreshToken,
        Claims = claims,
        Roles = roles
    });
}).RequireAuthorization();

Visiting /debug after signing in will show the ID token, access token, refresh token, and all user claims, making it easy to verify that your configuration is working correctly.