Skip to content

Setting up Argus to work with an external OpenID Provider - Implicit Flow

Defining new OpenID Provider

To define a new OpenID provider, use the /authentication/v1/openid/provider endpoint:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
curl -XPOST -H"Argus-API-Key: my/api/key" https://api.mnemonic.no/authentication/v1/openid/provider -d
    {
        "customer": "mycustomer",
        "shortName": "myprovider",
        "name": "My ADFS Provider",
        "clientID": "argusClient",
        "certificate": "MIIEtjCCAp4CCQDQSsrUHtwMmDANBgkqhkiG9w0BAQUFADAdMRs...",
        "providerURI": "https://my.provider/oidc/authorize",
        "issuer": "https://my.provider",
        "claimsMapping": {
            "userName": "user"
    }
}

In this setup, the claimsMapping specifies to use the claim "user", which should uniquely identify a user from this provider.
This could be a username, email, user-ID or similar, as long as it is unique, and always returns the same value for the same user.

Note

The certificate should be the same certificate as is defined in well-known OpenID configuration of your provider, which for an ADFS server can be found under https:///.well-known/openid-configuration

The certificate to submit to Argus should be the full base64-encoded JWKS certificate mentioned in the openid-configuration.

Note

The issuer must be the same as the iss claim returned in the id_token.

The issuer should be explicitly stated in https:///.well-known/openid-configuration

If issuer is not set, the issuer will default to expect a prefix of the providerURI.

Note

Some providers do not expose a certificate, instead the JWKS of the provider specifies a set of public key parameters. Instead of passing a base64-encoded X509 certificate, you can pass an entire base64-encoded JWKS file.

You should find the URL to your providers JWKS file in https:///.well-known/openid-configuration

1
2
3
4
5
6
curl -XPOST -H"Argus-API-Key: my/api/key" https://api.mnemonic.no/authentication/v1/openid/provider -d
    {
        ...
        "jwks": "MIIEtjCCAp4CCQDQSsrUHtwMmDANBgkqhkiG9w0BAQUFADAdMRs..."
        ...
    }

Note

When performing authorization of sensitive operations, it is advised to set up the OpenID provider to require the users username/password to verify user presence. Optionally, user presence may be confirmed without requiring password, depending on the providers OpenID support.

The option authorizationPrompt supports the three following OpenID options:

  • login - require user to enter username and password
  • consent - ask user to confirm without prompting for password
  • none - perform a standard authentication flow, do not require user confirmation
1
2
3
4
5
6
curl -XPOST -H"Argus-API-Key: my/api/key" https://api.mnemonic.no/authentication/v1/openid/provider -d
    {
        ...
        "authorizationPrompt": "MIIEtjCCAp4CCQDQSsrUHtwMmDANBgkqhkiG9w0BAQUFADAdMRs..."
        ...
    }

How this behaviour is implemented is up to the provider. Argus cannot control the details of how the provider verifies the user.

Note

Some providers do not support response_type=id_token which is the default flow.

Using the responseType option you can select type token or idTokenAndToken.

However, note that the current implementation requires that the provider redirects back with a valid id_token parameter.

1
2
3
4
5
6
curl -XPOST -H"Argus-API-Key: my/api/key" https://api.mnemonic.no/authentication/v1/openid/provider -d
{
...
"responseType": "token"
...
}