Important Security Considerations
General Client Considerations
The client requirements specified in OAuth 2.0 Security Best Current Practice and RFC-6819 MUST be implemented. Below and elsewhere, we only include some of the most important requirements to consider. This is not a complete list.
Configuration Data
The client must ensure that configuration information such as the address of the identity provider and the addresses of all APIs is securely delivered (e g over https), configuration is secure with appropriate access controls in place, cannot be modified by external means, e g by injection in urls, or through unsecure configuration retrieval. Failing to do so may expose tokens and sensitive information for example during login and logout, when calling APIs, and so on.
Public clients must never use or make the client_secret available to the end-user in any way, e g store it in a script file or make it accessible through an API.
Using Access Tokens
When authorization is completed, an access token is returned to the client. The access token is then sent to all API endpoints that requires it, as an Authorization HTTP header with the Bearer scheme:
The access token MUST NOT be stored on disk. If the user closes the browser or application, the access token MUST be erased/lost. Store the access token in memory or in sessionStorage if you are building a SPA (single-page application). See Maintaining session below for further information on how this relates to the refresh token.
Do not include the access token, refresh token or an id token as part of a url (including as a query parameter or as a fragment #) to prevent them from being stored in the browser´s history.
Tokens MUST NOT be sent to third party services/APIs, that is, tokens shall only be sent directly to the Momentum Fastighet API server. The client MUST at all times validate the certificate of the Momentum Fastighet API server (use HTTPS) and ensure that an attacker cannot inject or alter the address of the Momentum Fastighet API server. In addition, tokens MUST only be sent over secure transports, such as HTTPS.
Maintaining Session
A client or server/gateway MUST NOT store passwords or access_tokens. To maintain a session for end users, for a longer time than an issued access token allows, please request a refresh token by requesting the scope offline_access.
The refresh token is a secret and should be stored in a single location, on the client only and not on a server. Please use a secure storage mechanism when available. In a SPA, the refresh_token should typically be stored in localStorage (or using a more secure storage method when available). A refresh_token may not always be returned when requested due to policy or anomaly detection.
See Refresh Tokens for further information on how to use refresh tokens.