SSO2 Best practices

This page contains information on the best practices when implementing SSO2.

Identify

When to identify

Determining where to do the Identify-redirect may have implications on how your site works along with implications on performance. Choosing the right way for you use case is essential.

Identify at index page

Doing the Identify-redirect on your sites index page when a visitor does not have a session on your site will have the following implications

• A user that does not have a session on the site can be logged in automatically on the index page if the user have a active session in SSO2.
• This means that all users visiting the index page will be identified with increased load on the SSO2 Identify endpoint along with the landing-page of the site.

User not logged in on SSO2

(A) A user that does not have a session on the news-site visits the index page. The news-site backend does not have a SSO2 session id for the user. The user does not have a active session on SSO2.

(B) The backend returns a HTTP 302 redirect to the /identify endpoint in SSO2. Refer to the documentation for the /identify endpoint for further details.

(C) The users browser visits the /identify-endpoint, a session is established the users browser. The user is redirected to the landing-page of the Payway api client used.

(D) The users browser makes a HTTP GET request to the landing page as a result of step (C). The landing page establishes a session with the user. The SSO2 session session-id is stored in the session of the news-site for future use.

(E) The user browses to a locked article. The news site renders a paywall with the option to buy or log in.

(F) The user logs in by submitting credentials. The news-site backend authenticates with SSO2. The news-site exchanges the authorization ticket received for a access token. The access token is stored at the news-site and is used for PW API calls in context of the logged in user.

(G) After 6 minutes has passed since the last time the users SSO2 session was fetched; by either of the operations identify, authenticate or session status; the session status should be checked. See the session status for further information.

(H) When the user chooses to logout the news-site backend invokes the SSO2 logout operation.

User logged in on SSO2

(A) A user that does not have a session on the news-site visits the index page. The news-site backend does not have a SSO2 session id for the user. The user has a active session on SSO2.

(B) The backend returns a HTTP 302 redirect to the /identify endpoint in SSO2. Refer to the documentation for the /identify endpoint for further details.

(C) The users browser visits the /identify-endpoint, a session already exists with the users browser. The session is logged in, the user is known. The browser is redirected to the landing-page of the Payway api client used. The token sent back will include information needed to log the user in without performing a authenticates. See more information on logging the user in on the site here.

(D) The users browser makes a HTTP GET request to the landing page as a result of step (C). The landing page establishes a session with the user. The SSO2 session session-id is stored in the session of the news-site for future use, the authorization ticket received is exchanged for a access token and the user is logged in.

(E) The user browses to a locked article. The news site presents the article because the user is logged in.

(F) After 6 minutes has passed since the last time the users SSO2 session was fetched; by either of the operations identify, authenticate or session status; the session status should be checked. See the session status for further information.

(G) When the user chooses to logout the news-site backend invokes the SSO2 logout operation.

Identify at Paywall

Doing the Identify-redirect on the paywall / login form will have the following implications

• Users browsing the index page or articles that are not locked, will not be automatically logged in in the case they have a active session on SSO2.

User not logged in on SSO2

(A) A user that does not have a session on the news-site browses to a locked article. The news-site backend does not have a SSO2 session id for the user. The user does not have a active session on SSO2.

(B) The backend returns a HTTP 302 redirect to the /identify endpoint in SSO2. Refer to the documentation for the /identify endpoint for further details.

(C) The users browser visits the /identify-endpoint, a session is established the users browser. The user is redirected to the landing-page of the Payway api client used.

(D) The users browser makes a HTTP GET request to the landing page as a result of step (C). The landing page establishes a session with the user. The SSO2 session session-id is stored in the session of the news-site for future use.

(E) The users browser is redirected back to the locked article from step (A). The news site renders a paywall with the option to buy or log in.

(F) The user logs in by submitting credentials. The news-site backend authenticates with SSO2. The news-site exchanges the authorization ticket received for a access token. The access token is stored at the news-site and is used for PW API calls in context of the logged in user.

(G) After 6 minutes has passed since the last time the users SSO2 session was fetched; by either of the operations identify, authenticate or session status; the session status should be checked. See the session status for further information.

(H) When the user chooses to logout the news-site backend invokes the SSO2 logout operation.

User logged in on SSO2

(A) A user that does not have a session on the news-site browses to a locked article. The news-site backend does not have a SSO2 session id for the user. The user does not have a active session on SSO2.

(B) The backend returns a HTTP 302 redirect to the /identify endpoint in SSO2. Refer to the documentation for the /identify endpoint for further details.

(C) The users browser visits the /identify-endpoint, a session already exists with the users browser. The session is logged in, the user is known. The browser is redirected to the landing-page of the Payway api client used. The token sent back will include information needed to log the user in without performing a authenticates. See more information on logging the user in on the site here.

(D) The users browser makes a HTTP GET request to the landing page as a result of step (C). The landing page establishes a session with the user. The SSO2 session session-id is stored in the session of the news-site for future use, the authorization ticket received is exchanged for a access token and the user is logged in.

(E) The users browser is redirected back to the locked article from step (A). The news site presents the locked article because the user is logged in.

(F) After 6 minutes has passed since the last time the users SSO2 session was fetched; by either of the operations identify, authenticate or session status; the session status should be checked. See the session status for further information.

(G) When the user chooses to logout the news-site backend invokes the SSO2 logout operation.

Redirect as early as possible in the pipeline of your page

In order to have the smoothest experience when the redirect to /identify is done on your site, we recommend doing it in the backend of your site. This is to avoid loading unnecessary content of the page before the browser is redirected. If the redirect to /identify has to be made in Javascript on page loading we recommend doing it as early as possible in the page load process. Note that the redirect should not be made by XHR and doing this will not work as intended.

Do not redirect crawlers

Crawlers should not be redirected to /identify as they are prevented at the /identify endpoint in SSO2. A crawler reaching /identify will be met with a HTTP 403 Forbidden response. This will interfere with them crawling your site and will have a very negative effect on search engine indexing of your site.

Access tokens

Access tokens used for leveraging the Payway API:s are credentials and must be treated as such. Access tokens must be stored safely and never be exposed in browsers. A access token with an identity can still be used after a user is logged out of SSO2 using the logout operation. Because of that, implementers must ensure that access tokens are destroyed when a user is logged out of SSO2.