Entitlement Single Sign On (SSO)

customers usually expect that users who are logged in to the store are also logged in to the app/news website there are certain requirements to be met to make this work the requirements differ between the used entitlement types oauth2/openid entitlement this is a standard for single sign on, where a user is redirected to the website of an authentication provider, enters their credentials there and is logged in at the actual website / the app when redirected back how it works usually the authentication provider drops some cookies in the browser and thereby recognizes an active session so if the user is redirected to the website of the authentication provider while there is an active session, the authentication provider doesn't present the login form but immediately redirects back so if the shop and the app / website use the same oauth2/openid provider for login, a running session for the shop would be recognized when trying to login at the app how to handle sso in experience apps / websites starting in the app/website when a user is not logged in, they can access free content when the user wants to access paid content, they have to log in so they are redirected to the authentication provider, where they enter their credentials (or register for an account) and are finally redirected back to the app or website where they started in the case that the authentication provider detects a running session, the login form is not presented but the redirect occurs immediately after being redirected to the app or website, they are logged in and have access to the paid content (if they are authorized through the login, e g have a subscription) starting in the shop when the user logs in or registers at the shop without being directed there from the experience app or website and then opens the app or website manually or via a link from the shop, the app or website is in the not logged in state, presenting free content and a login button, when trying to access paid content to overcome this unpleasant state, the website should be opened with a path or query parameter to tell them, that the user is actually logged in in the experience context this would usually be a path like https //example com/autologin, which is backed by a view in the storefront implementation, which has the one task to force a login (as if the user had hit the login button) alternatively we could use a parameter like https //example com/any view?autologin=true to force the login as we have demonstrated above, experience would redirect to the authentication provider which detects the active session and immediately redirects back, with the user being logged in this works for apps as well, given that the shop is opened in an external browser (not an in app browser) when the shop redirects back to the app with the deeplink to the autologin view, the same flow (redirect to the authentication provider) would start under ios in this case a system popup would be displayed to ask for confirmation this doesn't work currently if the user is already logged in due to a limitation in the current implementation of the js api we enhance the apps so that they accept a js api login call even if a user is already logged in username/password entitlement an entitlement where the user has to enter their credentials directly in the app as well as in the shop are much harder to integrate, as there is no standard way to share sessions or handle redirects how it might work both the shop and the experience website/app have to share some knowledge about a session this might be a token, which is exchanged via url parameter starting in the app / website when a user is not logged in, they can access free content when the user wants to access paid content, they have to log in therefore a login form is presented where the user enters their credentials the app checks the credentials with the entitlement provider and if they are correct, the user is logged in and can access paid content (if they have a subscription) if the app presents a link to "the shop" (actually a "my account" page or similar), it would have to add a token to identify the logged in user as a parameter, like "https //example com/myaccount?token=xxxx" there is currently no standard way for the app / website to retrieve such a token so it is highly implementation dependent as a start there is an access token in the local storage of the website, which is a jwt, which can be parsed, which contains another jwt in its "sub" claim which can be parsed as well, which contains several claims one of them could be the one to use in a link to the myaccount page we will enhance the js api and graphql api so that experience can request an external token to be appended to the shop/myaccount url the shop/myaccount page is responsible to accept the token and log the user in starting in the shop if the user has not yet an account, they have to register therefore they would click a link which directs them to the shop, where they can do so after registration there would usually be a link to open the app or website, which they want to access in order to automatically login the user in the app or website, some token which identifies the user has to be appended to the link, like "https //example com?token=xxxx" upon startup the app or website would detect the token parameter and use it in a backend call to the "login with external token" endpoint if this succeeds, the user is logged in to the app / website and can access paid content this doesn't work currently if the user is already logged in due to a limitation in the current implementation of the js api we enhance the apps so that they accept a js api login call even if a user is already logged in