question-mark
Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

using refresh_token to get access_token does not contain previous claims

See original GitHub issue

Hi,

I have a custom AuthorizationController where I am using the password grant type to authenticate the user and adding some custom claims. This works fine and returns the JWT with additional properties.

However I’ve noticed when using a refresh token to get a new access token all these claims disappear, so the question is do I have to roll my own endpoint for refresh tokens to be able to set these claims again? If so are there any examples that may help.

Thanks

AuthorizationController

  public class AuthorizeController : Controller
    {
        public AuthorizeController(
            CustomOpenIddictManager userManager)
        {
            _userManager = userManager;
        }

        private CustomOpenIddictManager _userManager { get; set; }

        [HttpPost("~/connect/token")]
        [Produces("application/json")]
        public async Task<IActionResult> Exchange()
        {
            var request = HttpContext.GetOpenIdConnectRequest();

            if (request.IsPasswordGrantType())
            {
                var user = await _userManager.FindByNameAsync(request.Username);
                if (user == null)
                {
                    return BadRequest(new OpenIdConnectResponse
                    {
                        Error = OpenIdConnectConstants.Errors.InvalidGrant,
                        ErrorDescription = "The username/password couple is invalid."
                    });
                }

                // Ensure the password is valid.
                if (!await _userManager.CheckPasswordAsync(user, request.Password))
                {
                    if (_userManager.SupportsUserLockout)
                    {
                        await _userManager.AccessFailedAsync(user);
                    }

                    return BadRequest(new OpenIdConnectResponse
                    {
                        Error = OpenIdConnectConstants.Errors.InvalidGrant,
                        ErrorDescription = "The username/password couple is invalid."
                    });

                }

                if (_userManager.SupportsUserLockout)
                {
                    await _userManager.ResetAccessFailedCountAsync(user);
                }

                var identity = await _userManager.CreateIdentityAsync(user, request.GetScopes());

                // Create a new authentication ticket holding the user identity.
                var ticket = new AuthenticationTicket(
                    new ClaimsPrincipal(identity),
                    new AuthenticationProperties(),
                    OpenIdConnectServerDefaults.AuthenticationScheme);

                ticket.SetResources(request.GetResources());
                ticket.SetScopes(request.GetScopes());

                return SignIn(ticket.Principal, ticket.Properties, ticket.AuthenticationScheme);
            }

            return BadRequest(new OpenIdConnectResponse
            {
                Error = OpenIdConnectConstants.Errors.UnsupportedGrantType,
                ErrorDescription = "The specified grant type is not supported."
            });
        }

Issue Analytics

  • State:closed
  • Created 7 years ago
  • Comments:12 (5 by maintainers)

github_iconTop GitHub Comments

2reactions
kevinchaletcommented, Sep 4, 2016

This is the “expected” behavior, as custom claims are discarded when using a refresh token (because internally, OpenIddict calls CreateIdentityAsync to generate a fresh new identity and ignores the old claims).

That said, now that you’re responsible of creating authentication tickets, this behavior - inherited from the period where OpenIddict magically handled everything for you - doesn’t make much sense. Not sure what’s the best approach yet, but I’ll work on it.

1reaction
kevinchaletcommented, Oct 18, 2016

For reasons I can’t explain, the CodeFlow sample in the openiddict-samples repo already has the right scopes list, but not the sandbox sample used in this repo… most likely a brain bug :trollface:

Read more comments on GitHub >

github_iconTop Results From Across the Web

What Are Refresh Tokens and How to Use Them Securely
The client application can get a new access token as long as the refresh token is valid and unexpired. Consequently, a refresh token...
Read more >
identity server - get updated claims with refresh token
I am doing this using the refresh token to get a new access token but it comes with the same old claims inside;...
Read more >
Refresh Tokens - OAuth 2.0 Simplified
The presence of the refresh token means that the access token will expire and you'll be able to get a new one without...
Read more >
Refresh access tokens
This guide explains how to refresh access tokens with Okta. Learning outcomes. Understand how to set up refresh token rotation. Refresh access tokens....
Read more >
Refresh tokens in the Microsoft identity platform
A client can use a refresh token to acquire access tokens across any combination of resource and tenant where it has permission to...
Read more >

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Dev.to Post

No results found

github_iconTop Related Hashnode Post

No results found