Closed dhrp closed 6 years ago
I must disagree with you. Look at: https://openid.net/specs/openid-connect-discovery-1_0.html#rfc.section.4.1
4.1. OpenID Provider Configuration Request
An OpenID Provider Configuration Document MUST be queried using an HTTP GET request at the previously specified path.
The RP would make the following request to the Issuer https://example.com to obtain its Configuration information, since the Issuer contains no path component:
GET /.well-known/openid-configuration HTTP/1.1 Host: example.com
If the Issuer value contains a path component, any terminating / MUST be removed before appending /.well-known/openid-configuration. The RP would make the following request to the Issuer https://example.com/issuer1 to obtain its Configuration information, since the Issuer contains a path component:
GET /issuer1/.well-known/openid-configuration HTTP/1.1 Host: example.com
Using path components enables supporting multiple issuers per host. This is required in some multi-tenant hosting configurations. This use of .well-known is for supporting multiple issuers per host; unlike its use in RFC 5785 [RFC5785], it does not provide general information about the host.
Well; and I'll quote your quote, look at the part in bold:
The RP would make the following request to the Issuer https://example.com to obtain its Configuration information, since the Issuer contains no path component:
GET /.well-known/openid-configuration HTTP/1.1 Host: example.com
What I was suggesting was that the issuer MAY be the domain with no path. Currently the library does not allow one to specify it at all, and I think it will be a useful addition..
If you release OIDC application in urls under root path then issuer will contains only domain
From: Thatcher notifications@github.com Reply-To: juanifioren/django-oidc-provider reply@reply.github.com Date: Tuesday, 28 November 2017 at 12:19 To: juanifioren/django-oidc-provider django-oidc-provider@noreply.github.com Cc: Wojciech Bartosiak wojtek@flipsports.com, State change state_change@noreply.github.com Subject: Re: [juanifioren/django-oidc-provider] Let issuer be domain (#213)
Well; and I'll quote your quote, look at the part in bold:
The RP would make the following request to the Issuer https://example.com to obtain its Configuration information, since the Issuer contains no path component:
GET /.well-known/openid-configuration HTTP/1.1 Host: example.com
What I was suggesting was that the domain MAY be the domain. Currently the library does not allow one to specify it at all, and I think it will be a useful addition..
— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub, or mute the thread.
Would you welcome a PR that makes the path for the ISSUER configurable?
Sorry I was out of this conversation. @dhrp could you show me an example of an existing OP issuer is not the same as the root provider url. Thanks
Currently the 'issuer' for the id_token is generated with:
But there is no reason the 'issuer' has to include the some path. If you look at google, they have a clean issuer: https://accounts.google.com/.well-known/openid-configuration
What I propose is a simple setting to set the issuer using settings.
OIDC_ISSUER
. This would require the user to also make a route to the ProviderInfo on that issuer location.Do you welcome a PR?