Include id_token in ResponseType

[okta]

Include id_token in ResponseType

[laura-rodriguez]

have you created a groups claim in your application? In case you haven't, you can check how to do it here: https://developer.okta.com/docs/guides/customize-tokens-returned-from-okta/-/add-groups-claim-org-as/

[VijiMari]

thanks @laura-rodriguez. Found the missing bit.. its actually groups scope in Authorization servers,

[laura-rodriguez]

Hi @BrentSouza,

If you want to include groups as part of your claims, then you should go to your Okta Dashboard > API > Authorization Server. Once you select the AS you are using go to Claims tab and select Add Claim.
Select Groups in Value Type and then configure your desired configuration.

In this example, I configured to include this claim as part of profile so make sure you include profile as part of your scope:

app.UseOktaMvc(new OktaMvcOptions()
            {
             ...
             Scope = new List<string> {"openid", "profile", "email"},
            });

Of course, it depends on how you configure your claim.
The ResponseType is related to the OAuth flow. If you are using the authorization code flow, you are expected to use just code. In ASP.NET Core you have access to the tokens thanks to the SaveTokens property which is set to true when we register the OIDC middleware.
ASP.NET 4.x, is a different story and we have to include IdToken in the ResponseType.

Let me know if this works for you.

[BrentSouza]

Thanks. That does make sense but we are using the Okta auth server and not a custom auth server, so I don’t think we have the ability to modify the claims returned in each scope.

Is the expectation that we should be using custom auth servers?

[laura-rodriguez]

@BrentSouza , what do you mean with a custom auth server?
Anyways, you could also consider the Okta .NET SDK which allows you to manage Groups via the Groups API.

[justinhelgerson]

I think the point @BrentSouza is making is that the middleware for ASP.NET is specifying CodeIdToken whereas the middleware for ASP.NET Core is only specifying Code.

@BrentSouza you can always skip the Okta middleware provided through this library and configure however you need. Here's an example of what I'm doing:

.AddOpenIdConnect(options => {
    options.ClientId = oktaConfig.ClientId;
    options.ClientSecret = oktaConfig.ClientSecret;
    options.Authority = oktaConfig.Authority;
    options.CallbackPath = "/signin-oidc";
    options.ResponseType = OpenIdConnectResponseType.CodeIdToken;
    options.SaveTokens = true;
    options.UseTokenLifetime = false;
    options.GetClaimsFromUserInfoEndpoint = true;
    options.Scope.Add("groups");
    options.Scope.Add("email");
});

Then you can configure your app to include the group claims similarly to how @laura-rodriguez described.

[BrentSouza]

@laura-rodriguez this is what I am referring to:

https://okta.github.io/docs/how-to/creating-token-with-groups-claim

In the link above the auth servers are referred to by the terminology: Okta and Custom

Right now I don’t have custom authorization servers enabled in my organizations oktapreview account so I am testing with the Okta auth server and manipulating the claims is not exposed.

@justinhelgerson yes that is what I am referring to but I was really asking if the change was intentional. From Laura’s response it seems like it was and I will explore retrieving the id_token from the saved tokens.

@laura-rodriguez is this what you were referring to by accessing the saved tokens?

    string accessToken = await HttpContext.GetTokenAsync("access_token");
    string idToken = await HttpContext.GetTokenAsync("id_token");

[nbarbettini]

The difference in response_type between the two libraries is just an implementation detail (actually a limitation of the Katana middleware the AspNet library is based on). Both libraries end up with both an access token and an ID token at the end of the login flow. Any scopes in the ID token should be available as claims on the .NET ClaimsPrincipal.

Just to double check on your use case @BrentSouza:

1. You're authenticating against the Okta authorization server
2. The ID token returned includes a groups claim
3. You want to have access to the contents of the groups claim in your AspNetCore code

Does the ID token already have the claim you're expecting in step 2? AspNetCore receives access and ID tokens after it does a code exchange (backchannel), so the tokens won't be visible in the browser. You can use a tool like Fiddler to watch the tokens come back over the wire.

[BrentSouza]

@nbarbettini

1. You're authenticating against the Okta authorization server
2. The ID token returned includes a groups claim
3. You want to have access to the contents of the groups claim in your AspNetCore code

Yes to all 3.

What happens is that the ClaimsPrincipal doesn't contain the groups claim. If I get the id_token explicitly and decode the jwt, that also does not have a groups claim. I am using the okta-aspnetcore-mvc-example project to test things out. Relevant bits below:

Startup.cs

public void ConfigureServices(IServiceCollection services)
{
    var oktaMvcOptions = new OktaMvcOptions();
    Configuration.GetSection("Okta").Bind(oktaMvcOptions);
    oktaMvcOptions.Scope = new List<string> { "openid", "profile", "email", "groups" };
    oktaMvcOptions.AuthorizationServerId = "";

    services.AddAuthentication(options =>
    {
        options.DefaultAuthenticateScheme = CookieAuthenticationDefaults.AuthenticationScheme;
        options.DefaultSignInScheme = CookieAuthenticationDefaults.AuthenticationScheme;
        options.DefaultChallengeScheme = OktaDefaults.MvcAuthenticationScheme;
    })
    .AddCookie()
    .AddOktaMvc(oktaMvcOptions);

    services.AddMvc();
}

HomeController.cs

[Authorize]
public async Task<IActionResult> Profile()
{
    string idToken = await HttpContext.GetTokenAsync("id_token");
    string accessToken = await HttpContext.GetTokenAsync("access_token");
    return View(HttpContext.User.Claims);
}

HttpContext.User.Claims has the following claims:

• sub
• name
• email
• jti
• preferred_username
• given_name
• family_name

The decoded id_token has:

• sub
• name
• email
• ver
• iss
• aud
• iat
• exp
• jti
• amr
• idp
• nonce
• preferred_username
• auth_time
• at_hash

I feel like there's just something I'm missing. If I switch to using a hand-rolled AddOpenIdConnect similar to what @justinhelgerson wrote above, I do get the groups claim in the ClaimsPrincipal.

[nbarbettini]

@BrentSouza Sorry that we haven't followed up yet! There's something here, but I need to do some more investigation. You're not missing anything obvious 🙂

In the mean time, are you able to use AddOpenIdConnect so you're not blocked?

[laura-rodriguez]

Hi @BrentSouza ,
I know it's been a while since you opened this issue (Sorry about that!), but we finally fixed this recently as part of another task.
Now, In ASP.NET Core, if you set the property OktaMvcOptions.GetClaimsFromUserInfoEndpoint = true all the claims will be attached to the principal, groups among them.
You can see the details of the implementation here.
Basically, the issue was that in ASP.NET Core only certain claims are attached to the principal by default, that's why many of them weren't present before.
Thanks for all the info you provided!

[laura-rodriguez]

Fixed by #83.

[VijiMari]

This might be fixed for ASP.NET Core but the same issue seems to exist with .net framework. When I use okta-aspnet-mvc-example and add groups in the scope as shown below,

namespace okta_aspnet_mvc_example
{
    public class Startup
    {
        public void Configuration(IAppBuilder app)
        {            app.SetDefaultSignInAsAuthenticationType(CookieAuthenticationDefaults.AuthenticationType);
            app.UseCookieAuthentication(new CookieAuthenticationOptions());
            app.UseOktaMvc(new OktaMvcOptions()
            {
                OktaDomain = ConfigurationManager.AppSettings["okta:OktaDomain"],
                ClientId = ConfigurationManager.AppSettings["okta:ClientId"],
                ClientSecret = ConfigurationManager.AppSettings["okta:ClientSecret"],
                RedirectUri = ConfigurationManager.AppSettings["okta:RedirectUri"],
                PostLogoutRedirectUri = ConfigurationManager.AppSettings["okta:PostLogoutRedirectUri"],
                GetClaimsFromUserInfoEndpoint = true,
                Scope = new List<string> {"openid", "groups", "profile", "email"},
            });
        }
    }
}

it actually throws below error,

"OpenIdConnectMessage.Error was not null, indicating an error. Error: 'invalid_scope'. Error_Description (may be empty): 'One or more scopes are not configured for the authorization server resource.'. Error_Uri (may be empty): ''."

[laura-rodriguez]

Hi @VijiMari ,
What authorization server are you using?
An Okta Org Authorization Server authorization which endpoint looks like this:
https://${yourOktaDomain}/oauth2/v1/authorize

Or, a custom authorization server which endpoint looks like this:
https://${yourOktaDomain}/oauth2/${authServerId}/v1/authorize

You can find more info about authorization servers here: https://developer.okta.com/docs/guides/customize-authz-server/overview/

[VijiMari]

@laura-rodriguez - 'm using Okta Org Authorization Server