How to detect which identity provider send a response
Currently, I'm trying to implement an OpenID Connect solution which supports multiple identity providers. I chose to use the authorization code flow for this.
When the user opens the login screen the logo's of the supported identity providers are visible. When a logo/identity provider is clicked the system will store the necessary cookies and will redirect the user to the identity provider.
The response of the identity provider contains the following information:
- Authorization code
- Session_state
- State
- Scope
Now if I want to make a token request I don't know which identity provider to use. Some things I thought of two things to solve this issue:
- Using the UrlReferrer
- Storing the used provider in the cookies(Encrypted).
Does anyone know how to solve this problem?
single-sign-on oidc
edited Nov 26 '18 at 11:13
the_ultimate_developer
1,026822
asked Nov 26 '18 at 11:02
RonaldRonald
112
add a comment |
Currently, I'm trying to implement an OpenID Connect solution which supports multiple identity providers. I chose to use the authorization code flow for this.
When the user opens the login screen the logo's of the supported identity providers are visible. When a logo/identity provider is clicked the system will store the necessary cookies and will redirect the user to the identity provider.
The response of the identity provider contains the following information:
- Authorization code
- Session_state
- State
- Scope
Now if I want to make a token request I don't know which identity provider to use. Some things I thought of two things to solve this issue:
- Using the UrlReferrer
- Storing the used provider in the cookies(Encrypted).
Does anyone know how to solve this problem?
single-sign-on oidc
edited Nov 26 '18 at 11:13
the_ultimate_developer
1,026822
asked Nov 26 '18 at 11:02
RonaldRonald
112
add a comment |
Currently, I'm trying to implement an OpenID Connect solution which supports multiple identity providers. I chose to use the authorization code flow for this.
When the user opens the login screen the logo's of the supported identity providers are visible. When a logo/identity provider is clicked the system will store the necessary cookies and will redirect the user to the identity provider.
The response of the identity provider contains the following information:
- Authorization code
- Session_state
- State
- Scope
Now if I want to make a token request I don't know which identity provider to use. Some things I thought of two things to solve this issue:
- Using the UrlReferrer
- Storing the used provider in the cookies(Encrypted).
Does anyone know how to solve this problem?
single-sign-on oidc
edited Nov 26 '18 at 11:13
the_ultimate_developer
1,026822
asked Nov 26 '18 at 11:02
RonaldRonald
112
Currently, I'm trying to implement an OpenID Connect solution which supports multiple identity providers. I chose to use the authorization code flow for this.
When the user opens the login screen the logo's of the supported identity providers are visible. When a logo/identity provider is clicked the system will store the necessary cookies and will redirect the user to the identity provider.
The response of the identity provider contains the following information:
- Authorization code
- Session_state
- State
- Scope
Now if I want to make a token request I don't know which identity provider to use. Some things I thought of two things to solve this issue:
- Using the UrlReferrer
- Storing the used provider in the cookies(Encrypted).
Does anyone know how to solve this problem?
single-sign-on oidc
single-sign-on oidc
edited Nov 26 '18 at 11:13
the_ultimate_developer
1,026822
asked Nov 26 '18 at 11:02
RonaldRonald
112
edited Nov 26 '18 at 11:13
the_ultimate_developer
1,026822
asked Nov 26 '18 at 11:02
RonaldRonald
112
edited Nov 26 '18 at 11:13
the_ultimate_developer
1,026822
edited Nov 26 '18 at 11:13
the_ultimate_developer
1,026822
edited Nov 26 '18 at 11:13
the_ultimate_developer
1,026822
1,026822
asked Nov 26 '18 at 11:02
RonaldRonald
112
asked Nov 26 '18 at 11:02
RonaldRonald
112
asked Nov 26 '18 at 11:02
RonaldRonald
112
112
add a comment |
add a comment |
1 Answer
1
active
oldest
votes
Storing the provider details in session or in cookies would be the better option I guess as you might need to use other endpoints (such as introspection, certification) later in the flow.
answered Nov 27 '18 at 3:05
RakihthaRRRakihthaRR
304313
After reading the following article link I noticed that using the optional audience claim in the OAuth2 state is intended for storing the client(provider) the state is intended for. But should there not be a better way for doing this?
– Ronald
Nov 28 '18 at 17:26
Client is not the identity provider.audclaim in the token returns the application(s) which a user authorizes to access a certain resource on his behalf. This client should also be registered as a client in your IdP. Since the tokens returned are in the form ofjwt, you can validate the signature to determine whether the token has been tampered with.
– RakihthaRR
Nov 29 '18 at 2:28
add a comment |
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53479728%2fhow-to-detect-which-identity-provider-send-a-response%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
Storing the provider details in session or in cookies would be the better option I guess as you might need to use other endpoints (such as introspection, certification) later in the flow.
answered Nov 27 '18 at 3:05
RakihthaRRRakihthaRR
304313
After reading the following article link I noticed that using the optional audience claim in the OAuth2 state is intended for storing the client(provider) the state is intended for. But should there not be a better way for doing this?
– Ronald
Nov 28 '18 at 17:26
Client is not the identity provider.audclaim in the token returns the application(s) which a user authorizes to access a certain resource on his behalf. This client should also be registered as a client in your IdP. Since the tokens returned are in the form ofjwt, you can validate the signature to determine whether the token has been tampered with.
– RakihthaRR
Nov 29 '18 at 2:28
add a comment |
Storing the provider details in session or in cookies would be the better option I guess as you might need to use other endpoints (such as introspection, certification) later in the flow.
answered Nov 27 '18 at 3:05
RakihthaRRRakihthaRR
304313
After reading the following article link I noticed that using the optional audience claim in the OAuth2 state is intended for storing the client(provider) the state is intended for. But should there not be a better way for doing this?
– Ronald
Nov 28 '18 at 17:26
Client is not the identity provider.audclaim in the token returns the application(s) which a user authorizes to access a certain resource on his behalf. This client should also be registered as a client in your IdP. Since the tokens returned are in the form ofjwt, you can validate the signature to determine whether the token has been tampered with.
– RakihthaRR
Nov 29 '18 at 2:28
add a comment |
Storing the provider details in session or in cookies would be the better option I guess as you might need to use other endpoints (such as introspection, certification) later in the flow.
answered Nov 27 '18 at 3:05
RakihthaRRRakihthaRR
304313
Storing the provider details in session or in cookies would be the better option I guess as you might need to use other endpoints (such as introspection, certification) later in the flow.
answered Nov 27 '18 at 3:05
RakihthaRRRakihthaRR
304313
answered Nov 27 '18 at 3:05
RakihthaRRRakihthaRR
304313
answered Nov 27 '18 at 3:05
RakihthaRRRakihthaRR
304313
answered Nov 27 '18 at 3:05
RakihthaRRRakihthaRR
304313
304313
After reading the following article link I noticed that using the optional audience claim in the OAuth2 state is intended for storing the client(provider) the state is intended for. But should there not be a better way for doing this?
– Ronald
Nov 28 '18 at 17:26
Client is not the identity provider.audclaim in the token returns the application(s) which a user authorizes to access a certain resource on his behalf. This client should also be registered as a client in your IdP. Since the tokens returned are in the form ofjwt, you can validate the signature to determine whether the token has been tampered with.
– RakihthaRR
Nov 29 '18 at 2:28
add a comment |
After reading the following article link I noticed that using the optional audience claim in the OAuth2 state is intended for storing the client(provider) the state is intended for. But should there not be a better way for doing this?
– Ronald
Nov 28 '18 at 17:26
Client is not the identity provider.audclaim in the token returns the application(s) which a user authorizes to access a certain resource on his behalf. This client should also be registered as a client in your IdP. Since the tokens returned are in the form ofjwt, you can validate the signature to determine whether the token has been tampered with.
– RakihthaRR
Nov 29 '18 at 2:28
After reading the following article link I noticed that using the optional audience claim in the OAuth2 state is intended for storing the client(provider) the state is intended for. But should there not be a better way for doing this?
– Ronald
Nov 28 '18 at 17:26
After reading the following article link I noticed that using the optional audience claim in the OAuth2 state is intended for storing the client(provider) the state is intended for. But should there not be a better way for doing this?
– Ronald
Nov 28 '18 at 17:26
Client is not the identity provider.
aud claim in the token returns the application(s) which a user authorizes to access a certain resource on his behalf. This client should also be registered as a client in your IdP. Since the tokens returned are in the form of jwt, you can validate the signature to determine whether the token has been tampered with.– RakihthaRR
Nov 29 '18 at 2:28
Client is not the identity provider.
aud claim in the token returns the application(s) which a user authorizes to access a certain resource on his behalf. This client should also be registered as a client in your IdP. Since the tokens returned are in the form of jwt, you can validate the signature to determine whether the token has been tampered with.– RakihthaRR
Nov 29 '18 at 2:28
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53479728%2fhow-to-detect-which-identity-provider-send-a-response%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
