简体   繁体   中英

Silent login to AWS Cognito with external identity provider

We use AWS Cognito as the user management platform which come with AWS Amplify for our new project. But we also have KeyCloak as SSO for the organisation. So We connect KeyCloak as external IdP to the Cognito via OIDC to allow user login to our new system with organisation's SSO.

What we try to achieve is when user already login via organisation's SSO. They should be in logged in state when they visit this new site seamlessly.

However, Auth.currentSession() only recognised the login session from Cognito which mean it won't recognise the user have already login to the KeyCloak on the other website. The solution I comes up is try to use silentLogin from oidc-client to check the login state when the user visit. The silent login run an iframe to send request to the auth link. It first send the request to https://xxxxx.auth.ap-southeast-2.amazoncognito.com/oauth2/authorize with prompt=none to avoid showing the UI. But when the request got redirected to KeyCloak, it doesn't send with prompt=none which make it try to load the login UI and cause the silentLogin failed.

So I am wondering if there is anyway to edit the redirect url from Cognito to KeyCloak. Or any solution to achieve my goal can be suggested.

Thank you

The expected behavior should be like this - some UX stakeholders may not like the second redirect or consider it seamless but it has to happen like this:

  • User signs in via App A and has a Keycloak IDP cookie in the browser
  • Navigating to App B results in a top level redirect via Cognito to Keycloak but there are no authentication prompts due to the IDP cookie. Note also that this only works if there is a top level browser redirect, which serves as a user gesture.

Avoid the prompt=none technique, which is now deprecated:

  • You will not be able to change the message from Cognito to Keycloak since standards do not allow this
  • Cognito had never supported prompt=none
  • The Safari browser will drop the SSO cookie for this type of request

I would instead take a closer look at the HTTP messages for App B redirects:

  • Is the Keycloak IDP cookie sent (test this across a few browsers and look into reasons for dropped cookies)
  • If the cookie is sent, then is there anything in the messages, such as prompt=login, or the Keycloak session settings that may require each app to authenticate?

The technical post webpages of this site follow the CC BY-SA 4.0 protocol. If you need to reprint, please indicate the site URL or the original address.Any question please contact:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM