nonce query parameter not sent in case of oidc implicit flow

[SzymonKlimuk]

• swagger-ui version 3.0.17 and 3.1.2

Hello, we are testing swagger ui with authentication on keycloak. When using implicit flow, keycloak returns error because it expects nonce parameter in the query.

As described here: http://openid.net/specs/openid-connect-core-1_0.html#ImplicitFlowSteps

nonce is REQUIRED.

I think for the swagger ui it may be any random nonce (no pass our tests we added dummy nonce=1234)

So I think the solution would be to add:

query.push("nonce=" + )

in

oauth2-authorize.js

in case of implicit flow.

Regards,

Szymon Klimuk

[rousku]

I'm having exactly the same problem with keycloak. I "fixed" it with additional query parameters: additionalQueryStringParams: {'nonce': '325qjlalf09230'}

[SzymonKlimuk]

It can be fixed in src/core/oauth2-authorize.js by updating implicit flow case:

case "implicit":
  function randomNonce(length) {
    var text = "";
    var possible = "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789";
    for(var i = 0; i < length; i++) {
      text += possible.charAt(Math.floor(Math.random() * possible.length));
    }
    return text;
  }

  query.push("response_type=token")
  query.push("nonce=" + randomNonce(12))
  break

[webron]

OIDC is currently not supported in Swagger-UI. It will be introduced with the official support for OAS3 with its internal OIDC support.

[wlami]

OIDC is currently not supported in Swagger-UI. It will be introduced with the official support for OAS3 with its internal OIDC support.

As far as I understand there is support for OAS 3.0 in Swagger UI 3.18.3. However, OIDC is not yet implemented. Is it being worked on/ is there a roadmap when OIDC support will come? If not, are you open for contributions on this feature?

[SzymonKlimuk]

I pasted the solution before. Just let us know if we can PR this.

[wlami]

I pasted the solution before. Just let us know if we can PR this.

I agree that your posted solution helps, as sending a nonce is required for OIDC.

But I think it is not sufficient for OIDC conformance. The spec says that response_type may contain id_token and token. Right now only token is hard coded for implicit flow. What I actually meant with "OIDC is not yet implemented" is that adding type: openIdConnect and openIdConnectUrl: /.well-known/openid-configuration should be enough to set up OIDC. At leastt this is what the documenation at https://swagger.io/docs/specification/authentication/openid-connect-discovery/ says.

[styk-tv]

@wlami from what I understand:

One of .well-known/openid-configuration-listed endpoints is called certs (jwks_uri). It carries a list of dictionaries that are compliant with JWK (Json Web Key RFC 7517). In my Keycloak there is only one and it carries enough info to reconstruct a public key that is required to verify a signature of a JWT token.

in python RSAAlgorithm.from_jwk(keys[0]) where RSAAlgorithm comes from jwt package and keys is a direct output of certs endpoint.

Once signature on token is verified to be coming from the .well-known server, there are usually other checks like audience, expiry and so on.

As an an example unrelated directly to openapi specification i will list below kubernetes spec to demonstrate the difference in groups handling. It is fascinating to observe details of implementation of this single file over the last two years and the oidc setup being reduced to below:

spec:
  kubeAPIServer:
    oidcIssuerURL: https://your-oidc-provider.svc.cluster.local
    oidcClientID: kubernetes
    oidcUsernameClaim: email
    oidcGroupsClaim: groups  

Then in our JWT token:

might then very easily translate to in openapi.yaml:

paths:
  /pets/{petId}:
    get:
      summary: Get a pet by ID
      security:
        - openId:
          - api-user

Reason I'm listing this is I believe it is important to observe implementation that cares where the GroupClaims are coming from. As you are crafting the token, groups can be placed in different locations. I use groups, but as you are defining a mapping it could be any name. I have not seen such placeholder in the OpenApi3 Discovery specification. I would kindly ask you consider this during implementation.

So (imho) OpenIDConnect (OIDC) should care not directly about .well-known endpoint which is global to the oidcIssuer but rather on these 4 elements that are required to determine WHO against the OpenAPI security(openId) WHAT:

1. oidcIssuerURL: (server + realm) from which the .well-known endpoints can be derived (usually by affixing .well-known/openid-configuration)
2. oidcClientID: there might be one but as much as hundreds of clients (consumers) of the oidc details in a single realm. Each could have different flows of authorization or mappings (what data is in the token)
3. oidcUsernameClaim: what field is defines the unique user identifier
4. oidcGroupsClaim: what field holds the list of groups that user belongs to (based on this we can grant permissions to different api endpoints) could be as easy as pets_read, pets_write, admin or as complex as required to handle enterprise-level ldap-provided group membership mappings that span across hundreds of endpoints.

In Summary: OpenID Connect Discover (oidc) is very close from being fully realized in python for OpenApi. Personally I have both beautiful dreams and nightmares about this section for a long time. I think for all of us, getting to a point where you can use abstracted system like Keycloak, Auth0, Google, Cognito ... with or without federated LDAP that admit control to selected endpoints based on token's self-contained details is very long awaited.

[asyba]

any news about this issue?

[indiealexh]

Would love an update, this issue is causing delays.

[linjmeyer]

Hi @SzymonKlimuk - like the others i'm wondering if there is an update on this issue? Is there anything the community can do to help? We make heavy use of Swagger UI (and Swashbuckle) and have been holding off on finalizing our OIDC implementation until it's supported by Swagger UI. Thanks!

[SzymonKlimuk]

Hi, I am not part of the community I just found the bug and proposed the solution. Probably you need to ask @webron

[dentych]

What is going on with this issue? It has been lying here for over a year now, opened two years ago.

This page about OAS3 links to this issue as a tracker of when OpenID Connect will be working in Swagger UI.

We tried using OAuth2, but have two problems. Nonce is not set, and we can't specify our own response_type. Our OIDC server does not support response_type=token, so we effectively can't use Swagger to login, but have to create another website to retrieve a JWT token, and then use a simple Bearer setup in Swagger, where one can input the received token...

[SzymonKlimuk]

Hi, we are using the swagger UI with the keycloak. We have the fix I proposed implemented (https://github.com/swagger-api/swagger-ui/issues/3517#issuecomment-324285279) and everything (4 flows) is working fine

[lockenj]

@SzymonKlimuk could you provide some more details. I am following https://swagger.io/docs/specification/authentication/openid-connect-discovery/#swagger-ui but when my swagger-ui is rendered the "authorize" button just pops up a blank modal box.

[lsiepel]

Any update on workaround or real support for OIDC ?

[rukgar]

Same issue here @SzymonKlimuk. I have included your fix but OpenID auth method is showing a blank box. And no auth...

[SzymonKlimuk]

Hi, As I wrote, we tested it with the Keycloak. What authorisation provider are you using? What version of swagger UI are you using?

[fagnercarvalho]

Does anybody knows if this was implemented or not?

[xantari]

Does anybody knows if this was implemented or not?

I just get blank box like @rukgar , So I would say it is not...

[cpesch]

Does anyone work on a fix?

[cjamesrohan]

We are also waiting for this update. Blank modal with OIDC configuration. Cannot use OAuth2 configuration due to lack of nonce and incorrect response_type.

[vbjay]

Being able to pass in the authority and having the swagger ui use that result to access the OIDC would be a great option.

Why can't we do this

 c.AddSecurityDefinition("oauth2", new OpenApiSecurityScheme
                {
                    Type = SecuritySchemeType.OAuth2,
                    Flows = new OpenApiOAuthFlows
                    {
                        ClientCredentials = new OpenApiOAuthFlow
                        {
                            Authority="Oauth server URL"
                            Scopes = new Dictionary<string, string>
                            {
                                { "Some_Scope", "Create thing" }
                            }

                        }
                    }
                });
            });

swaggerui then uses that and uses OIDC to get the TokenUrl and such?

[t-rad679]

Hello! Any update on this?

I tried the workaround in https://github.com/swagger-api/swagger-ui/issues/3517#issuecomment-324283757 and it didn't make any difference for me. I also noticed that my IDE did not like the field name additionalQueryStringParams. It wanted me to add x- in front of it. Any idea what I'm doing wrong there, or any other ideas of how to make this work?

[dafo]

We are facing the same issue so an update on this problem would be of great help for us - at least for estimating purposes.

[Ghostbird]

I have a similar looking issue, the Authorize UI does not show up, more specifically SwaggerUI never makes the call to the discovery endpoint at all.

c.AddSecurityDefinition("token", new OpenApiSecurityScheme {
    Type = SecuritySchemeType.OpenIdConnect,
    OpenIdConnectUrl = new Uri(apiConfiguration.Authority),
    Description = "Authorize Swagger to make API calls on your behalf."
});
c.AddSecurityRequirement(new OpenApiSecurityRequirement {
{
    new OpenApiSecurityScheme {
        Reference = new OpenApiReference {
            Type = ReferenceType.SecurityScheme,
            Id = "token"
        }
    },
    new[] { "apiAccess" }
},

Note: apiConfiguration.Authority is the authority uri-string read from the config.

[Urr4]

Any updates?

[hpl002]

updates welcome

Any updates?

+1

[Alex-Torres]

Updates +1

[fleporcq]

Updates +1

[ThoSap]

Updates +1

[Arul-]

Looking forward to the update!

[ryanrishi]

For anyone unable to authorize in Swagger UI, you can also add ?nonce=1 to the authorization url in your spec, eg. https://example.okta.com/oauth2/ausv0hn8k9yuDyjxs0j7/v1/authorize?nonce=1

Note: skipping nonce validation exposes you to replay attacks and should not always be verified if you need to trust the token. More info here.

[rokroskar]

I don't think 0a26916 resolved this issue - it now correctly parses oidc information but it still does not supply nonce in the implicit oauth2 flow, causing keycloak to abort.

[lovasoa]

I still see this issue too

[inouiw]

I created a workaround using wrapActions that uses the implicit grant flow with id_token and nonce. A working example is at https://github.com/inouiw/SwaggerUIJsonWebToken