Authentication and authorization
Corteza implements the OAuth2 authentication protocol. The Corteza server can act both as an OAuth2 server and as an OAuth2 client, allowing internal and external authentications.
Refer to the OAuth2 spec for a complete reference to the protocol.
Why OAuth2 rework?
-
OAuth2 is a proven and well-accepted authentication standard.
-
Corteza becomes more open and easier to integrate with different applications.
-
It fits well into the existing RBAC security model.
-
Personalized authentication page lets users feel safe when entering their credentials.
-
Trivial Corteza authentication user interface modification.
Terminology
In OAuth2 terminology, this is a resource owner The user authenticates themselves and authorize the <<,auth-client,client>> on the authorization server. |
|||
In OAuth2 terminology, this is an *authorization server* The Corteza Auth authenticates users, authorizes clients, and issues access tokens. More details can be found here.
|
|||
In OAuth2 terminology, this is a *resource server* A client must obtain an access token in order to access the resources on the Corteza API.
|
|||
A client is any application that is being used to interact with the Corteza API. |
|||
Local credentials are the email and the password that the user can use to authenticate. |
|||
An external identity provider is any provider that supports the OpenID Connect (OIDC) protocol, such as Google, LinkedIn, and GitHub. |
|||
The security context is a set of roles assigned to the user when accessing the Corteza API. More in the auth scope section. |
Corteza Auth server
Enables users to allow applications access to the Corteza API resources without sharing their actual credentials. This happens through the secure exchange of credentials, codes, secrets and tokens following the OAuth2 protocol.
After a successful authorization with local credentials or an external provider, an access token along with a refresh token is issues. This should be done automatically by the client.
The session on the Corteza Auth is different from the one on the client application. This separation allows the Corteza Auth session to be used when authorizing additional clients.
|
Since the authentication sessions between different clients are different, you must revoke each session for the user to be "truly signed-out". |
Authorization scope
The scope is defined as a series of role memberships that are either permitted, prohibited, or forced on the user when using a specific Corteza Auth server.
Permitted roles Permitted roles allow you to specify what roles the user is allowed to have when accessing the Corteza API resources from a specific client. |
Prohibited roles Prohibited roles allow you to specify what roles the user is not allowed to have when accessing the Corteza API resources from a specific client. |
Corteza Auth security features
Authentication forms and endpoints are protected against brute-force and cross-site request attacks. You can also set your secrets for JWT, CSRF and cookie value encryption.
Different expiration durations can be set on sessions temporary and permanent sessions to support your organization’s security policies.