Session Overview¶
Target Audience: Users, Developers, Stakeholders
Warning
Please note: We do not recommend that you implement SSO using this system. This system will be obsolete in the future. Please implement Single Sign-On using Single Sign-On v2 (SSO2), read more here.
Introduction¶
This section describes the Payway session concept. The centralized session enables support for Single sign on and Single sign out. To establish the session a Payway login is performed. It is also possible to use Payway without the Payway session
Payway Identity¶
In payway an identity consists of an account coupled to a organisation. The organisation is your Payway instance. The user creates his account in your instance. This means that the same user can have several identities in Payway that belongs to different Payway instances.
The Payway session¶
The Payway session is established when the user logs into Payway and builds on one identity. The session is cookie based and the cookie is stored on the Payway server domain (backend.worldoftulo.com).
A session can be short-lived or long-lived when the user selects the "remember me" option. There can only be one session at a time in Payway per user agent. This means that if the user wants to assume another identity, the session must be logged out and a new one created. When the user visits another Payway instance the session is automatically logged out.
Payway login¶
To create a session in Payway the user's browser is redirected to the Payway server where the user enters his username and password to establish a session. If the users arrives at to the Payway server and a session has already been established, the user is sent back to the application without entering his credentials.
Payway logout¶
The user is redirected to the logout endpoint on the Payway backend and the session is destroyed. After that the user is sent back to the original page.
Parameters¶
| Parameter | Description |
|---|---|
| continue | The user is redirected back to the address supplied in this parameter after the session is destroyed. The redirect is done via Javascript on the page served at the endpoint for logging out. |
Endpoints¶
| Environment | Address |
|---|---|
| stage | https://payway-api.stage.adeprimo.se/oauth2/logout |
| production | https://backend.worldoftulo.com/oauth2/logout |
SSO using Javascript API¶
Payway support single sign on within a instance using the centralized session.
A typical scenario using the SSO goes as following:
- User does not have session in Payway
- User arrives at your application
- User is redirected to Payway Server using the Javascript API
- User performs a Payway login to establish a Payway session
- User is sent back to your application
- User arrives at another of your applications
- Using the Javascript API your application becomes aware that the user has a session
When the user has performed a Payway login he will also have access to the Payway functions such as My account and purchase flow without having to log in again.
SSO using OAuth2 tokens¶
Using the OAuth2 authorization code flow you may achieve SSO without using the Javascript API. The benefits of this method is that it offers you greater control and also access to Payways API. The drawback is that you have to do a bit more integration implementation on your backend.
This integration method does not support single sign out. You may use the Payway logout to destroy the session in Payway. The Payway logout does not destroy any access-tokens, so applications that already has their tokens are not affected. The user must perform a Payway login on the next application that does not already have a token.
Example¶
- User arrives at app1.com
- APP1 starts OAuth2 authorization code flow
- User performs a Payway login
- User arrives at app1.com/redirect_uri and collects an access-token
- APP1 starts a local session and stores the access-token
- User arrives at app2.com
- APP2 starts OAuth2 authorization code flow
- Since the user has already performed a Payway login he is sent back to app1.com/redirect_uri without entering credentials
- APP2 gets an access-token and starts a local session
- User logs out from APP2
- APP2 destroys its local session
- APP2 does a Payway logout
- User goes to app1.com and is still logged in since APP1 has a local session with access-token
- User goes to app3.com
- APP3 starts OAuth2 authorization code flow
- User has to enter credentials again because APP2 performed a Payway logout
Payway without Payway session¶
You may also use Payway without using Payway's centralized session and manage the session yourself. You can leverage the power of the Payway API using the Password Grant and the Client Credentials flows. You must implement your own SSO if you need such functionality. One disadvantage of this is that Payway's applications (such as my account and purchase flow) is not then included in the SSO.