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.