Oidc-client-js: Allowing custom parameters to be set in the signin request.

Created on 24 Apr 2017  路  17Comments  路  Source: IdentityModel/oidc-client-js

Hey, I am using this library for implementing the implicit flow and the I want to send a custom parameter (realm_id) in the authorization url.
It'll be great if there's an option of adding a custom parameter in the sign in url.

Thank you !

enhancement

Most helpful comment

Thanks for the changes!

For posterity:

const userManager = new UserManager({ ... }); //as normal
await userManager.signinRedirect({
    extraQueryParams: { //your params go here
        foo: 'bar',
        batz: 'quux', 
    },
});

All 17 comments

What's realm_id? Is that in the spec?

This is a custom field being used by our app. A realm is used for grouping clients. A realm_id is then further used for authorization.

This is not in specs, it would be awesome if there's a way to add a custom params in the signin url.

Editing the initial comment.

If you're using IdentityServer then we recommend using acr_values=idp:yourrealm as a home realm hint.

Hey, we are using an in-house IAM server which expects a realm_id in the signin url. This logic is very custom to satisfy some business requirements. Adding a way to add custom parameters, maybe a callback which gets called just before the signin url is formed, would make this library more flexible to use.

Nimbus OAuth SDK does provide a way to add custom parameters, please find this below:
https://connect2id.com/products/nimbus-oauth-openid-connect-sdk/examples/oauth/authorization-request

I would gladly like to have this feature as well for a different use case. When authenticating with google's authority, you can provide an extra parameter called hd to limit the host domain that people can use to sign in. This is mostly a cosmetic thing but it can also help users with multiple google accounts (like people with a personal gmail account and a work google apps account) to use the right one when signing in.

Understood. The current issue is that right now the param is an object and we look for explicit protocol params. I'd need to figure out how to indicate other params that are custom/non-protocol to include.

Something like this would be good. I am currently using the userManager.createSigninRequest, then append the custom parameters to the URL and redirect myself.

Passing it (somehow) as a signinRedirect parameter would be nice. (Maybe the createSigninRequest(args) method or _signinStart(args) of the UserManager is a good place to do this? Idk. )

I agree. We want to send a custom parameter from the client, because we use the SAML plugin Kentor Authservice which redirects to a Federation. If we supply an EntityId as a parameter the Federation's Discovery Service gets overriden and user is redirected to the correct IDP (instead of choosing one from the DS).

Hi guys, do ye have a sense as to when this might be fixed? (ie. when might https://github.com/IdentityModel/oidc-client-js/pull/355 be merged?).

It would be great to have access to this functionality soon in my scenarios.

Thanks for a great project!

Not for a bit -- I'm traveling.

Thanks for the the update @brockallen. Have a good trip!

Done, thanks!

Thanks for the changes!

For posterity:

const userManager = new UserManager({ ... }); //as normal
await userManager.signinRedirect({
    extraQueryParams: { //your params go here
        foo: 'bar',
        batz: 'quux', 
    },
});

So, I don't want the extra param encoded into the ReturnUrl (state). I need send over the app's language so the login can be in the currect language. Any way to do that?

/?culture=fr-CA&ReturnUrl=....

I'll have to research if there is a way to get .NET Core's IdentityServer4 to handle it. Thanks!

@sikemullivan they should be in Parameters of AuthorizationRequest

Was this page helpful?
0 / 5 - 0 ratings

Related issues

bialabs picture bialabs  路  3Comments

slug56 picture slug56  路  4Comments

rmja picture rmja  路  3Comments

tomeinar picture tomeinar  路  3Comments

StephenRedd picture StephenRedd  路  5Comments