Skip to content

Latest commit

 

History

History
121 lines (89 loc) · 3.79 KB

README.md

File metadata and controls

121 lines (89 loc) · 3.79 KB
Raw

OIDC compatible Fake IdP service for testing

This is a HTTP(S) based service with a valid key and discovery endpoint that allows to generate JWT tokens based on the claims you like to receive.

WARNING: This is a test service, don't use the keys and the service as such in a production setup as it allows you to create any kind of JWT token signed by the given keys.

Version 0.3 and on

COMMAND LINED ARGUMENTS CHANGED AS OF VERSION 0.3.0

The -s for static is no -f for folder (serving the html for login)

The -h for the exposed host is now -e (that makes the help work as it should)

Running the service

Running the binary works follows:

fakeidp
Allows to generate any valid JWT for OIDC

❯ ./target/debug/fakeidp --help
Usage: fakeidp [OPTIONS] [KEYFILE]

Arguments:
  [KEYFILE]  Location of the RSA DER keypair as a file

Options:
  -p, --bind-port <BIND_PORT>
          Sets the port to listen to [default: 8080]
  -b, --bind-host <BIND_HOST>
          Sets the host or IP number to bind to [default: 0.0.0.0]
  -e, --exposed-host <EXPOSED_HOST>
          Full base URL of the host the service is found, like https://accounts.google.com [default: http://localhost:8080]
  -f, --folder <FOLDER>
          Folder for the static files to serve [default: ./static]
  -h, --help
          Print help information
  -V, --version
          Print version information

Generate keys

The mock service makes use of DER encoded key files. The easiest way to generate these are the openssl tool

openssl genpkey -algorithm RSA \
                -pkeyopt rsa_keygen_bits:2048 \
                -outform der \
                -out private_key.der

Note that a keypair is provided by default.

The other option is to run it as a DOCKER container:

docker run -p9090:9090 -e BIND=0.0.0.0 -e PORT=9090 -e EXPOSED_HOST=http://localhost:9090 spectare/fakeidp:latest

where BIND and PORT are environment variables that allow you to change the endpoint binding and address within the container. Note that you need to expose the port you choose and match that with the exposed host name/port. EXPOSED_HOST is the base URL used by the outside world to find the ./well-known/openid-configuration and the keys.

Use it for manual OIDC Login

At this moment it is possible to use a simple implicit flow (response_type=token%20id_token&scope=openid) and trigger a login screen. Within the screen you can setup your sub(ject) - most of the times your account ID and your name. the .well-known/openid-configuration endpoint returns the proper authorization endpoint (/auth)

NOTE: PKCE FLOW IS NOT YET SUPPORTED

Example for JWT token creation

The service runs by default on port 8080 and in order to generate a token, you post the required claimset to the /token endpoint

curl -d "@claim.json" -X POST http://`hostname -f`:9090/token

where claim.json contains the claimset:

{
  "iss": "http://localhost:8080/mock",
  "sub": "CgVhZG1pbhIFbG9jYWw",
  "aud": "cafienne-ui",
  "exp": 1576568495,
  "iat": 1576482095,
  "at_hash": "zqKhL-sV6TNJUFQSF7PwLQ",
  "email": "[email protected]",
  "email_verified": true,
  "name": "admin"
}

Example for userinfo

When you need to mock your userinfo call, you can create a token with the above example and thereafter do a GET on the /userinfo enpoint with an 'Authorization' header including 'Bearer ' where is the generated token of the example.

Note that your claims need to contain the fields you want to return for userinfo. Currently supported are:

{
  "iss": "http://localhost:8080",
  "sub": "F82E617D-DEAF-4EE6-8F96-CF3409060CA2",
  "email": "[email protected]",
  "email_verified": true,
  "name": "Arie Ministrone"
}

Name, email and email_verified. The other 2 are required for generation of the token and are used in the validation.