forked from osredm/PHengLEI-docs
18 lines
1.5 KiB
Markdown
18 lines
1.5 KiB
Markdown
|
# Security
|
||
|
|
|
||
|
|
In general most OAuth 2.0 security guidelines apply to Jackson as well but there are a few minor differences.
|
||
|
|
|
||
|
|
## Tenancy
|
||
|
|
|
||
|
|
OAuth 2.0 is typically a single instance and all users can login using the same instance. However SAML is based on an specific instance that your customers have to configure with their Identity Provider. This means that access to the SAML instance is limited to only those that have been provisioned for it, adding another layer of security to the login flow.
|
||
|
|
|
||
|
|
## Client Secret
|
||
|
|
|
||
|
|
The Config API returns a `client_id` and `client_secret` that you can save for each customer and use when initiating the OAuth 2.0 flow. However for convenience we also let you use a `tenant` and `product` instead since this doesn't require you to store any additional data. When using this we recommend you use the [CLIENT_SECRET_VERIFIER](./deploy/env-variables.md#client_secret_verifier) configuration and not use the default `dummy` value. The `client_secret` cannot really be misused because as you will see in the next section the tokens are short lived but it is a good idea to set the `client_secret` to something that is really a secret.
|
||
|
|
|
||
|
|
For client-side logins we highly recommend you use the PKCE flow which is supported by Jackson. This ensures a secure login without revealing the `client_secret` on the client-side.
|
||
|
|
|
||
|
|
## Tokens
|
||
|
|
|
||
|
|
The tokens generated by Jackson are short lived (default is 5 minutes) and hence there is no risk of it being misused even if the `client_secret` is known. Your SAML provider ensures that there can be no unauthorized.
|