I see an 'end_session_endpoint' property in 4.2. OpenID Provider Configuration Response. However, it is not found in 3. OpenID Provider Metadata. It was also not found in rfc8414.
Does this mean that OIDC has deleted this attribute?
https://openid.net/specs/openid-connect-discovery-1_0.html
https://www.rfc-editor.org/rfc/rfc8414.txt
Related
I'm running Keycloak 4.8.3 server for identity brokering, and I need to add an external OIDC identity provider that does not support client_id/client_secret authentication. This identity provider only supports private_key_jwt and PKCE authentication.
Unfortunately, Keycloak server only allows me to add OIDC identity providers with client_id and client_secret authentication. Is there any way around this? Maybe a plugin I can install for Keycloak server that allows me to add an identity provider with private_key_jwt authentication?
I have requested this feature and it has been identified as a legitimate feature request for which support should be added:
https://issues.jboss.org/browse/KEYCLOAK-9809
Hello friendly StackOverflowers,
we are using WSO2 Identity Server 5.6.0 and are trying to use OpenID Connect to secure applications.
I followed https://docs.wso2.com/display/IS560/Configuring+Claims+for+a+Service+Provider and created custom external oidc claims mapping to local claims. I also added the oidc claims to the oidc file in the registry.
It appears though, that the documentation is not fully up to date as there is an additional dropdown in 5.6.0 with the Service Provider Claim Dialect.
When we try to login, the login itself works, but the claims are not attached to the id token correctly. Even though the claim manager was able to retreive the claims, as I see in the logfile.
I tried a couple different variations (Custom Claim Dialects, Local Claim Dialect and also choosing just the Service Provider Claim Dialect), but nothing worked.
Interestingly:
If I choose a claim as the subject, and the consent is given by the user, the claim is attached to the id token - even if I remove it from the subject again.
I managed to get all the claims working, by choosing them as the subject, one by one, and giving consent during the login.
This however only works for this particular user.
Anyone got a pointer to how I have to configure the OpenID claims in 5.6.0? In 5.3.0 they did work with the same configuration.
Regards,
Mat
I want to use AWS cognito as a OpenId connect provider.My AWS cognito IDP will intern call my another OpenId provider to authenticate the user. It will then create its new token and hand over to callers as its own.
The OpenID provider used internally by AWS cognito pool is transparent to user. User only configures AWS cognito as its IDP provider.
User case
User authenticates with My AWS IDP provider
My IDP provider authenticates the user agains Googles IDP provider
My IDP decodes the token returned by Google IDP.
My IDP Creates new token and add additional claims.
My IDP hands over my JWT to user.
Question
Is this possible in AWS cognito?
Does AWS user pool expose OpenID connect endpoint?
Cognito does provide an OpenId connect endpoint, as detailed in this blog post by #Badri
The formula for the authority is:
https://cognito-idp.{region}.amazonaws.com/{userPoolId}
And you can verify by checking the metadata URL that something is there
https://cognito-idp.{region}.amazonaws.com/{userPoolId}/.well-known/openid-configuration
Then during client pool setup, you can federate with other OIDC providers, and also enable the OIDC provider in the app client settings. Which should enable your scenario which sounds very similar to what I would like to do. However, the blog post misses one crucial piece of configuration, which is setting a domain name for the app integration. This StackOverflow question shows the error you will receive if you do not configure this domain and links to the solution in an answer. Once I set the domain, Badri's code worked for me.
To give a more detailed answer on Cognito's OpenID Connect support.
Discovery Endpoint
Cognito exposes an OpenID Connect Discovery endpoint as described at https://openid.net/specs/openid-connect-discovery-1_0.html#ProviderConfigurationRequest at the following location:
https://cognito-idp.{region}.amazonaws.com/{userPoolId}/.well-known/openid-configuration
Response Types
The above endpoint returns the following three response_types:
"response_types_supported":["code","token","token id_token"]
code: defined in https://www.rfc-editor.org/rfc/rfc6749#section-11.3.2 - this worked for us, but only when a domain was specified as below.
token: this value is forbidden by OpenID Connect at https://openid.net/specs/openid-connect-core-1_0.html#ImplicitAuthRequest - "NOTE: While OAuth 2.0 also defines the token Response Type value for the Implicit Flow, OpenID Connect does not use this Response Type, since no ID Token would be returned." - OpenID Connect libraries will ignore this response.
token id_token: this value triggers a redirect to an error page with the code "invalid_request". There is no indication given as to what is invalid with the request. AWS technical support claim that only "code" and "token" are supported by authorize endpoint, it is however not clear why this response_type is advertised if not supported.
Domain
Cognito gives the option to specify a domain that will prefix the hostname of the Cognito endpoint.
Without a domain being specified, Cognito will advertise generic URLs at the OpenID Connect discovery endpoint such as https://cognito-idp.eu-west-2.amazonaws.com/{userPoolId}/authorize, but all attempts to log in at these URLs return the error message:
{"code":"BadRequest","message":"The server did not understand the operation that was requested.","type":"client"}
The error message does not indicate what is bad about the request, so this appears to be a bug in Cognito.
With a domain specified, Cognito will advertise URLs that include the domain prefix, and the response_type "code" returns a login page as expected.
Logout
OpenID Connect Session Management at https://openid.net/specs/openid-connect-session-1_0.html#RPLogout describes how an OpenID Connect logout must be initiated, and requires as per https://openid.net/specs/openid-connect-session-1_0.html#OPMetadata that the end_session_endpoint parameter be included in the discovery metadata.
In the case of Cognito end_session_endpoint is omitted from the metadata.
RP-Initiated Logout at https://openid.net/specs/openid-connect-session-1_0.html#RPLogout describes how the logout endpoint works. If an attempt is made to pass the logout endpoint manually to the OpenID Connect client implementation, logout fails as follows:
{"code":"BadRequest","message":"The server did not understand the operation that was requested.","type":"client"}
Again, the error message gives no indication of the error, however the description of the logout endpoint at https://docs.aws.amazon.com/cognito/latest/developerguide/logout-endpoint.html shows no compatibility with OpenID Connect.
While you can log into Cognito using OpenID Connect, there is no option to log out.
Cloudformation
Cognito Cloudformation support is incomplete, and affects OpenID Connect as follows:
There is no way to specify a domain using Cloudformation, and the domain is required for OpenID Connect to work.
The callback URL is required by OpenID Connect, but cannot be set using Cloudformation.
Summary
To access Cognito using OpenID Connect, ensure that a domain is specified, and use the response_type "code" only. OpenID Connect logout is not possible. Other options violate the OpenID Connect specification, or were released broken.
I'm having a little trouble following your use case, but I'll explain some points that might help.
You can use Cognito User Pools to authenticate users through Google, and then issue JWT tokens from the Cognito User Pool. See the Developer Guide.
Cognito User Pools is not currently a full OpenID identity provider, but that is on our roadmap. User Pools do support OAuth2.0 flows, and they do provide OpenID standard JWT tokens.
I looked at mule-oauth2.xsd and found only client credentials and authorization grant type elements. However, looking at the oauth2-provider:config it can be configured as supportedGrantTypes="RESOURCE_OWNER_PASSWORD_CREDENTIALS". If it does support resource owner password credentials, how can I configure an oauth2-client to retrieve a token? I am looking at retrieving a token from the OAuth2 provider using the oauth2:client. Here is an example of what I'm referring to, however, I want to achieve this for password.
<http:request-config name="requestConfigWithOAuth">
<oauth2:client-credentials-grant-type
clientId="${client.id}"
clientSecret="${client.secret}"
tokenManager-ref="tokenManagerConfig">
<oauth2:token-request tokenUrl="${token.url}"/>
</oauth2:client-credentials-grant-type>
</http:request-config>
#Breen-
yes Mule provides Password Grant type. I recently configured for my APIs. In API management console, when you generate a client application , it provides an option for different grant types to select which is out of the box from MULE. you do not have to do any set up for this. It is through API management console on Anypoint platform.
Let me know if any question.
MuleSoft supports the following authentication in Mule 3.8 client apps:
Basic Authentication
NTLM Authentication
Digest Authentication
OAuth2 - Authorization Code
OAuth2 - Client Credentials
See the docs.
We are using WSO2 IS 4.5.0 for our product implementation. We are implementing SAML2 based SSO between our product applications. And our REST APIs are secured using OAuth2. Now, we are trying to configure IS to issue SAML2 bearer token for OAuth applications.
These are the steps that we followed
Added a tenant 'sample.com'
Added SAML SSO service provider (travelocity.com) within tenant 'sample.com'
Added OAuth application within tenant 'travelocity'
Added Trusted Identity Provider as defined in SAML2 Bearer Assertion Profile for OAuth 2
Added wso2carbon.jks public certificate to Trusted Identity Provider [This is the same certificate used during SAML Authentication Request generation]
And when I try to invoke OAuth2Service.issueAccess, I get the following error
Signature was either invalid or signing key could not be established as trusted
Any help to resolve will be highly appreciated.
We have missed configuring public certificate of the tenant 'sample.com' in trusted identity provider configuration, that resolves the issue!