Open ID Connect issues and questions

[Justincale]

Apologies for the lengthy question, but i have been playing around with implementing OIDC within Oqtane for an existing downstream API for a few weeks now and am still struggling to get this working. @sbwalker, you may have received a communication from @kevinchalet over at openiddict which is related to the following.

I'll begin by describing my current system and how everything fits together.

I have an existing API which i am attempting to create an Oqtane client (clients) for.

Each client must be able to access the API by retrieving a token from a custom open id connect server (i am currently utilizing openiddict for this). Tokens can be retrieved both before someone has logged in (via a client_credentials call), or after login (via an authorization_code call). I am able to successfully log a user in using Oqtane's built in external login settings/login page etc. This was achieved by following the details of this blog post: https://www.oqtane.org/blog/!/37/oauth-2-0-and-openid-connect

These are the issues i am having:

1: The siteState.AuthorizationToken is only populated after a user logs in, and there doesn't seem to be a way for me to retrieve a token from openiddict via a client_credentials call. I have tried a workaround by utilizing my own HttpClient and manually calling openiddict using client_credentials, but this results in a token issued by my openiddict server, not the Oqtane Implementation, which screws up my API token validation.

2: The example from the above blog post link requires me to register a specific client Issuer and IssuerSigningKey in my API token Validation, such as:

.AddJwtBearer(options => {
options.RequireHttpsMetadata = false;
options.SaveToken = true;
options.TokenValidationParameters = new TokenValidationParameters()
{
ValidateIssuerSigningKey = true,
ValidateIssuer = true,
IssuerSigningKey = new SymmetricSecurityKey(System.Text.Encoding.UTF8.GetBytes("*************************")),
ValidIssuer = "https://localhost:44357",
ValidateAudience = false,
ValidateLifetime = true,
ClockSkew = TimeSpan.FromDays(1)
};
});

This is problematic when i have multiple API Clients (which can be generated by my users programmatically). It seems that this solution has, perhaps, been designed with a single, known client in mind. The way this would usually work is that the token received by the API would be issued by the open id connect server and would either use a secret that both the API and ID server know, or would use introspection to call the ID server and validate the token that way.

So, as it stands, i am either able to configure my API to receive tokens that were issued by openiddict via a client_credentials call (which are validated by using either a secret shared between the API and openiddict, or introspection), or configure my API to receive tokens from the Oqtane client which are validated using the secret shared between the API and Oqtane. What i 'believe' i need is for the access token retrieved from openiddict as part of the authorization_code flow to be passed directly on to my API (as it is when using client_credentials), where i can introspect or decode it (but, again, my knowledge on this is limited). If this is achievable, i am happy to maintain my own HttpClient for client_credential calls (although if this could be baked into the existing RemoteServiceBase that would also be good).

Any help or advice would be really appreciated, and happy new year. :)

[sbwalker]

Including my previous answer below...

The current implementation of auth was designed to cater to a number of different use cases:

1. Ability for a user to authenticate locally using self-hosted .NET Identity which generates a cookie including their local role assignments.
2. Ability to for a user to authenticate using a 3rd party Identity Provider (ie. OAuth2 or OIDC). Once a user is authenticated they are mapped to a local user in the Oqtane application which is used to generate a cookie including their local role assignments.
3. Ability for an authenticated user to generate a JwT token based on their cookie which can be passed to a remote API (ie. using RemoteServiceBase)

It sounds like what you want is the ability for Oqtane to act as a proxy and pass the access token from the Identity Provider to a remote API. This scenario was never implemented which is why you are struggling to get it to work.

[sbwalker]

The article at https://www.oqtane.org/blog/!/37/oauth-2-0-and-openid-connect is related to item 3 above - it demonstrates how to use Oqtane to generate a JwT token and validate it in a downstream API. Based on my recollection the AddJwtBearer method has a lot of properties which can be configured based on your specific needs ie. specify ValidateIssuer = false or specify ValidIssuers if you want to include multiple upstream authorities.

[Justincale]

Yes, I could skip issuer validation but I would also have to skip token validation as my api clients can be created ad-hoc, which ends up being a security risk. The only solution is to validate tokens that were issued by my open id server.

Do you think a solution for this scenario would ever be implemented in Oqtane, or do I roll my own?

Thanks

[Justincale]

I have already hit issues with the cookie size limits when SaveTokens = true. Based on a conversation with Kevin over at openiddict, and this repo: https://github.com/openiddict/openiddict-samples/tree/dev/samples/Dantooine there are three options which are outlined in that repo's AuthenticationController.LogInCallback

  // Multiple strategies exist to handle OAuth 2.0/OpenID Connect callbacks, each with their pros and cons:
  //
  //   * Directly using the tokens to perform the necessary action(s) on behalf of the user, which is suitable
  //     for applications that don't need a long-term access to the user's resources or don't want to store
  //     access/refresh tokens in a database or in an authentication cookie (which has security implications).
  //     It is also suitable for applications that don't need to authenticate users but only need to perform
  //     action(s) on their behalf by making API calls using the access token returned by the remote server.
  //
  //   * Storing the external claims/tokens in a database (and optionally keeping the essential claims in an
  //     authentication cookie so that cookie size limits are not hit). For the applications that use ASP.NET
  //     Core Identity, the UserManager.SetAuthenticationTokenAsync() API can be used to store external tokens.
  //
  //     Note: in this case, it's recommended to use column encryption to protect the tokens in the database.
  //
  //   * Storing the external claims/tokens in an authentication cookie, which doesn't require having
  //     a user database but may be affected by the cookie size limits enforced by most browser vendors
  //     (e.g Safari for macOS and Safari for iOS/iPadOS enforce a per-domain 4KB limit for all cookies).
  //
  **//     Note: this is the approach used here, but the external claims are first filtered to only persist
  //     a few claims like the user identifier. The same approach is used to store the access/refresh tokens.**

Perhaps there is an argument for an extensibility point in Oqtane? i.e. Module developers could write their own login callback handler which deals with storing the access and refresh tokens?

[Justincale]

Hi @sbwalker, Any thoughts on the above. I'm quite desperate to deploy but am unable to due to SaveTokens being set to false in Oqane. I think defaulting it to true is NOT the way to go due to the size limitation on the auth cookie and it may be a gotcha for some, but if i could have the ability to manually set this via a user setting that would be great. Developers could then choose depending on their situation.

thanks

[sbwalker]

@Justincale I think it does make sense to include this as an option (default to False). Once this is implemented does it also mean that the existing logic in OnTokenValidated() which adds the access token to the Identity cookie should be removed:

   identity.AddClaim(new Claim("access_token", context.SecurityToken.RawData));

[Justincale]

Great, thanks Shaun.

As far as i understand it, the access_token being set in OnTokenValidated is actually an id_token which can't be sent to an API anyway, but there are claims in there which, if made available, would be very handy for me to get my hands on from within Oqtane. My auth provider, for instance, returns granular permissions for the user related to my custom system. At the moment, i am having to create a kind of dummy Profile setting (and profile mapping within the user settings) so that Oqtane can map and store them for me.

With that in mind, my suggestion would be to replace:

identity.AddClaim(new Claim("access_token", context.SecurityToken.RawData));

with something like:

// include id token claims
foreach(var claim in context.SecurityToken.Claims)
{
identity.AddClaim(new Claim("idt_" + claim.Type, claim.Value));
}

Where "idt_" is just a prefix to negate clashes with claim names. Module devs working with an external provider will know which claims they need, and can retrieve them from the ClaimsPrinciple in Oqtane, while the actual access_token from the auth provider (which shouldn't be accessed by the client), can be stored in the auth cookie (Savetokens = true) and sent to the api.

The above would solve 90% of my issues (which is great for now), but i think there may be scope in the future to implement a better way of storing the access_token retrieved from the auth provider (to negate the size limits of the auth cookie), and adding a proper proxy (such as YARP) to manage calls to the external API, client_credential calls to the auth server, and refresh tokens etc.

Thanks again.

[sbwalker]

#4983 adds the Save Tokens option to External Login

[Justincale]

Thanks Shaun.

[sbwalker]

@Justincale In regards to RemoteServiceBase I believe you are suggesting that if a user had previously authenticated using an IDP that the auth token they received from the IDP should be passed to the downstream API? There is also the case where a user is using local authentication and will have no auth token, and in this case Oqtane could include its own auth token that it generates to send to the downstream API. Does this make sense? The one scenario this does not support is if a user wanted to authenticate remotely against an IDP but wanted to use Oqtane's auth token for downstream APIs (ie. they want to use Oqtane's roles rather than what is defined in the IDP) - not sure if this is an edge case.

[Justincale]

Yes, this is correctJustinOn 18 Jan 2025, at 3:01 am, Shaun Walker ***@***.***> wrote: @Justincale In regards to RemoteServiceBase I believe you are suggesting that if a user had previously authenticated using an IDP that the auth token they received from the IDP should be passed to the downstream API? There is also the case where a user is using local authentication and will have no auth token, and in this case Oqtane could include its own auth token that it generates to send to the downstream API. Does this make sense? The one scenario this does not support is if a user wanted to authenticate remotely against an IDP but wanted to use Oqtane's auth token for downstream APIs (ie. they want to use Oqtane's roles rather than what is defined in the IDP) —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: ***@***.***>

[Justincale]

Yes, this is correct, and my suggestion above regarding saving IDP claims to the Oqtane claims principle would give developers access to those claims in Oqtane without needing to map them to profile settings (some claims may not be profile specific and may not even need to be persisted anywhere)