richard.chetwynd | July 24th, 2018
We recently released a update to our OpenId Connect (OIDC) provider that makes our well-known configuration document validate correctly with clients that strictly enforce the OpenId Connect specification.
What was the problem?
If you’re currently using our OpenId Connect provider then you will know that your primary OIDC endpoint is an extension of your custom OneLogin subdomain.
E.g. https://my-domain.onelogin.com/oidc
This is great, and all of the OpenId Connect flows work as expected, however if you use a client that uses automatic Discovery of the available features and endpoints then you may have run into trouble with the “issuer” url not matching the url of the configuration document or other urls in the document.
Not all clients had trouble with this, but some strictly validate against the spec and since we had a url mismatch they would fail to initialize. An example of this is the Go OIDC client, which also happens to be used by Kubernetes. Therefore if you use Kubernetes and want to authenticate with OneLogin, you had to jump through some hoops to make it work. This recent change removes all that pain.
What’s changed?
We now recommend that all clients switch from using the custom subdomain version of the OIDC provider to a generic version that applies to all OneLogin accounts. We have a separate endpoint for our customers in Europe, so you will use one of the following endpoints depending on the location of your OneLogin instance.
- Worldwide: https://openid-connect.onelogin.com/oidc
- Europe: https://openid-connect-eu.onelogin.com/oidc
You will notice that the well-known configuration document for these domains is now valid with all the urls matching the base url of the request.
For example: https://openid-connect.onelogin.com/oidc/.well-known/openid-configuration will return the following configuration document.
{
"acr_values_supported": ["onelogin:nist:level:1:re-auth"],
"authorization_endpoint": "https://openid-connect.onelogin.com/oidc/auth",
"claims_parameter_supported": true,
"claims_supported": [
"acr",
"auth_time",
"company",
"custom_fields",
"department",
"email",
"family_name",
"given_name",
"groups",
"iss",
"locale_code",
"name",
"phone_number",
"preferred_username",
"sub",
"title",
"updated_at"
],
"grant_types_supported": [
"authorization_code",
"implicit",
"refresh_token",
"password"
],
"id_token_signing_alg_values_supported": ["RS256"],
"issuer": "https://openid-connect.onelogin.com/oidc",
"jwks_uri": "https://openid-connect.onelogin.com/oidc/certs",
"request_parameter_supported": false,
"request_uri_parameter_supported": false,
"response_modes_supported": ["form_post", "fragment", "query"],
"response_types_supported": ["code", "id_token token", "id_token"],
"scopes_supported": ["openid", "name", "profile", "groups", "email", "phone"],
"subject_types_supported": ["public"],
"token_endpoint": "https://openid-connect.onelogin.com/oidc/token",
"token_endpoint_auth_methods_supported": [
"client_secret_basic",
"client_secret_post",
"none"
],
"userinfo_endpoint": "https://openid-connect.onelogin.com/oidc/me",
"userinfo_signing_alg_values_supported": [],
"code_challenge_methods_supported": ["plain", "S256"],
"introspection_endpoint":
"https://openid-connect.onelogin.com/oidc/token/introspection",
"introspection_endpoint_auth_methods_supported": [
"client_secret_basic",
"client_secret_post",
"none"
],
"revocation_endpoint":
"https://openid-connect.onelogin.com/oidc/token/revocation",
"revocation_endpoint_auth_methods_supported": [
"client_secret_basic",
"client_secret_post",
"none"
],
"claim_types_supported": ["normal"]
}
Does this impact the user experience?
No. After switching over to use one of these generic OIDC subdomains your users will not notice a difference in user experience. They will still be prompted with the same login page that they are accustomed to seeing with your app. And if they look at the address bar in their browser they will see your custom subdomain.
Can I still use the custom subdomain version?
Yes. We will keep both options available for backwards compatibility but it is likely that in the future we could deprecate this so if you’re just starting out with OIDC at OneLogin you should use these generic subdomains.
Rich Chetwynd founded Litmos, the market-leading learning technology company, as well as ThisData, a data security company leading the way in Account Takeover (ATO) attack detection. After ThisData was acquired by OneLogin in Summer 2017, Rich began working with the OneLogin engineering team with a focus on adaptive authentication.