Add support for OpenID Connect Discovery

[urkle]

OpenID Connect discovery is a protocol that would allow an application to discover the OAuth 2 endpoints and specifics in a standardized fashion.. e.g. a user could specify the following

Site: https://acccount.example.org/
Client ID : clientid
Client Secret: clientsecret

Then postman can simply do a GET for https://account.example.org/.well-known/openid-configuration this will return a JSON hash that will contain the rest of the needed information.
Example:

{
    "issuer":"https://account.example.org",
    "jwks_uri":"https://account.example.org/jwks.json",
    "response_types_supported":["code"],
    "subject_types_supported":["public","pairwise"],
    "id_token_signing_alg_values_supported":["RS256"],
    "authorization_endpoint":"https://account.example.org/authorizations/new",
    "token_endpoint":"https://account.example.org/access_tokens",
    "userinfo_endpoint":"https://account.example.org/user_info",
    "scopes_supported":["openid","profile","email"],
    "grant_types_supported":["authorization_code","refresh_token"],
    "request_object_signing_alg_values_supported":["HS256","HS384","HS512"],
    "token_endpoint_auth_methods_supported":["client_secret_basic","client_secret_post"],
    "claims_supported":["sub","iss","name","email"]
}

Matching up with the current OAuth2 form in postman,

• "authorization_endpoint" is the Auth URL
• "token_endpoint" is the Access Token URL
• "scopes_supported" is the scopes (just change that to a space delimited list)
• "grant_type_supported" can be used to choose the best grant type.

More information can be found https://openid.net/specs/openid-connect-discovery-1_0.html

[lorenzleutgeb]

Could you please motivate why the client ID and the client secret have to be known? Maybe I missed something, but I think that just the base URL before the /.well-known/openid-configuration is required. Also note that this might not be just a domain name, but really a URL, as exemplified in the referenced spec.

[thomaslevesque]

Could you please motivate why the client ID and the client secret have to be known?

The client ID is always a required parameter, in all authentication flows. The client secret is required in some flows (client credentials, authorization code without PKCE). It's not possible to obtain a token without these parameters.

[lorenzleutgeb]

OK, then this was a misunderstanding. It was mentioned since it is required to get a token, not since it is required to get the discovery information...

[friedrich-brunzema]

The discussion above seems to point to pointing to the well-known endpoint to get info about the IDP url's. But I think what is needed is a way to exchange the username/password (possibly client secret) for an auth token without UI, so this can work in a headless (newman) way. I have written such a utility that works against keycloak. Internally it impersonates a web browser, parses the HTML and adds the creds to the form and posts back to the IDP. Problem with that approach is that every IDP generates different HTML, making the code fragile. The redirect url contains the secret with which you can then call the token endpoint.

[telyn]

I think what is needed is a way to exchange the username/password (possibly client secret) for an auth token without UI, so this can work in a headless (newman) way [...] Problem with that approach is that every IDP generates different HTML, making the code fragile. The redirect url contains the secret with which you can then call the token endpoint.

It's a little off-topic to the issue we're discussing this on, but, I think this is a deliberate design decision of OpenID Connect - it does not want to limit the ways that systems could authenticate with a particular system. It's a silly example, perhaps, but consider a support site for an appliance manufacturer.

Instead of a traditional username + password, you could log in using the model number and serial number of your fridge to see messages you've exchanged with the support site. If the manufacturer then added a discussion forum it could use the support site as an IDP - but still without requiring the traditional username and password.

It's definitely impossible to come up with a general solution that will always work - the web browser impersonation method is really the only way to work, I think, unless you can convince the devs for the product you're working with to add an API to log in with :-)

Back on topic though - where I work we're currently working on documenting our API via our test suite - preventing us from letting the documentation get out of sync with the reality of the product. documentation for the OpenID configuration & scopes and such has been left as a TODO, in part because we didn't fully understand the OpenAPI spec format at the time, and in part because we knew that the OpenID scopes wouldn't import into Postman anyway. I think we're going to compromise on documenting it as if it's plain OAuth2 (in the hopes that Postman will grok it, and because most of our API calls won't have any dependency on OIDC anyway). Would be great if Postman could import + display the scopes somewhere to help with configuring authentication for different requests.

[edumueller]

Could you please motivate why the client ID and the client secret have to be known? Maybe I missed something, but I think that just the base URL before the /.well-known/openid-configuration is required. Also note that this might not be just a domain name, but really a URL, as exemplified in the referenced spec.

I understand where you come from, but that's basically to make sure you are getting the "configs" for that specific client (thus the id)

[edumueller]

In my collection, I've added a call to the discovery endpoint and a Test Script that sets some variables.

Then, before clicking the "get token" button, I can just run this script and populate the variables being used in my collection's "Authorization" tab.

You can probably play around and improve it, but here it is:

pm.test("Discovery is working and variables were set", function () {
    if (pm.response.code != 200) {
        pm.sendRequest(pm.request, function (err, r) {
            if (r.code == 200) {
                return setCollectionVariables(r)
            }
            throw new Error("Error: request failed");
        })
    } else {
        return setCollectionVariables(pm.response)
    }
});

function setCollectionVariables(rdata) {
    let { authorization_endpoint, token_endpoint, scopes_supported, grant_types_supported } = rdata.json();

    pm.collectionVariables.set('authorization_endpoint', authorization_endpoint);

    pm.collectionVariables.set('token_endpoint', token_endpoint);

    if (typeof scopes_supported == 'object')
        scopes_supported = scopes_supported.join(' ').trim()

    pm.collectionVariables.set('scopes_supported', scopes_supported);

    pm.collectionVariables.set('grant_types_supported', grant_types_supported);

    return true
}

[Brutus5000]

Any plans in this direction?