Simple OAuth2 authorization server for the integration tests pipeline
1.4K
The Test OAuth2 Authorization Server is designed to be a simple solution for the integration test pipeline when the service being tested is expecting the third parth OAuth2 provider to authorize incoming calls.
This implementation supports Authorization Code, Client Credentials and Token Refresh flows as well as JWT and Opaque tokens.
The clients can only be statically configured via environment variables, i.e. you cannot add them on fly and tokens and users only exist in memory.
In order to configure clients set up environment variables. Each OAuth2 client environment variable is prefixed with CLIENTS_
prefix immediately followed by the name of the client. So, for example, if the clients name is test then their configuration
environment variables will be prefixed with CLIENTS_TEST_.
Similarly, users entries are prefixed with USERS_. Again, if username is test, then their environment variables
will be prefixed with USERS_TEST_.
You also can configure the audience for the tokens by setting AUTHORIZATION_SERVER_API_AUDIENCE. If not overridden, the
default value is test-authorization-server.
In order to configure client following set of environment variables will be used (the sample variables configure client
with the name test).
| Variable Name | Mandatory? | Default Value | Description |
|---|---|---|---|
| CLIENTS_TEST_CLIENT_AUTHENTICATION_METHODS | No | client_secret_basic | Comma separated list of authentication methods this client supports |
| CLIENTS_TEST_CLIENT_ID | Yes | N/A | Client ID. Normally, we use a random generated string |
| CLIENTS_TEST_CLIENT_SECRET | Yes | N/A | Client Secret. Again, normally it is a randomly generated string, however when it is set here it must be bcrypt encoded and have {bcrypt} prefix |
| CLIENTS_TEST_SCOPES | Yes | N/A | Comma separated list of the client's scopes |
| CLIENTS_TEST_TOKEN_FORMAT | No | self-contained | The type of token client supports. It is either self-contained, i.e. JWT or reference, i.e. opaque |
| CLIENTS_TEST_GRANT_TYPES | No | client_credentials | Comma separated list of the supported grant type. Allowed values are: client_credentials, authorization_code and refresh_token |
| CLIENTS_TEST_TOKEN_TTL | No | 3600 | Number of seconds the produced token is valid for |
Here is the list of the allowed CLIENT_AUTHENTICATION_METHODS:
Here is an example of the client's secret environment variable:
CLIENTS_BCITEST_CLIENT_SECRET={bcrypt}$2y$05$EbjNftcLQLv.4td5BOjAhemjHAVIpbGowI9I.UbI.EfplytQDhLe2
In order to configure user for the authorization code flow, use the following variables. Again, the sample environment
variables configure user test. To configure user with the different name replace TEST after USER_ prefix with
the desired username.
| Variable Name | Mandatory? | Default Value | Description |
|---|---|---|---|
| USER_TEST_PASSWORD | Yes | N/A | Bcrypt encoded user's password. Should have a {bcrypt} prefix |
| USERS_TEST_ROLES | No | N/A | Comma separated list of the user roles. Technically not mandatory, but only in the cases when all that matters is that user has been authenticated |
Example of the user's password environment variable is as follows:
USERS_TEST_PASSWORD=$2y$05$h3LqmKYtq8/RFIm0Rqm90ObP5J.LAEPJlthV0t8yPxe1jnIblODKK
Content type
Image
Digest
sha256:97f9a6dac…
Size
253.4 MB
Last updated
about 1 year ago
docker pull iktech/test-authorization-server