Swagger-ui: Oauth2 password flow

[reginaldlouis]

Hi. I'm trying to use the oauth2 feature with password flow from swagger 2.0 spec. I dont' know if I'm doing thing wrong or if there some missing stuff, but let me explain. This is my spec:

swagger: '2.0'

info:
  title: BakPak API
  description: BakPak server API
  version: '1.0.0'

host: localhost:5000
basePath: /api/v1

schemes:
  - http
  - https

consumes:
  - application/json

produces:
  - application/json

securityDefinitions:
  basicPassword:
    type: oauth2
    flow: password
    tokenUrl: http://localhost:5000/api/v1/token
    scopes:
      s1: Scope 1
      s2: Scope 2

paths:
  /token:
    get:
      tags:
        - auth
      summary: Get an authentication token
      description: Get an authentication token
      operationId: GetToken
      responses:
        '200':
          description: ""
        default:
          description: Operation failed.
  /test:
    get:
      summary: Test endpoint
      description: Test endpoint
      responses:
        '200':
          description: ""
        default:
          description: Operation failed.
      security:
        - basicPassword:
          - s1
          - s2  
  /user:
    post:
      tags:
        - user
      summary: Add a user
      description: Add a user
      operationId: AddUser
      parameters:
        - name: body
          in: body
          description: Type can be `bp`, `facebook` or `google`.
          schema:
            $ref: '#/definitions/Credentials'
      responses:
        '200':
          description: ""
        default:
          description: Operation failed.

definitions:
  Credentials:
    properties:
      type:
        type: string
      username:
        type: string
      password:
        type: string
      token:
        type: string

I have a /test endpoint just to test oauth2. I remove the comment in index.html to enable oauth2 flow:

            initOAuth({
              clientId: "your-client-id",
              realm: "your-realms",
              appName: "your-app-name"
            });

When I click on the "on/off" button to authorize, a new windows browser is opened with the following url http://localhost:5000/swagger-ui/null&redirect_uri=http://localhost:5000/swagger-ui/o2c.html&realm=your-realms&client_id=your-client-id&scope=s1,s2.

Note the null in the url. It is normal? I'm not super familiar with every aspect of oauth, but I was expecting a popup for username/password and somehow receiving at some endpoint a POST with a
application/x-www-form-urlencoded in the request body like this:
grant_type=password&username=johndoe&password=A3ddj3w

reference: http://tools.ietf.org/html/rfc6749#section-4.3.2

[webron]

Right now, the UI only supports the implicit flow for OAuth2, and even that was a (great) community contribution. If you think you can help us to add support for the password flow, that would be great.

[bshamblen]

@webron I'd like to submit a pull-request to fix some of the issues with oauth2 security settings, to get it to work with the 2.0 spec. I've already identified and fixed a few minor things in the swagger-oauth.js file. The read.me file says to only make changes to the coffeescript files, but i don't see one for the swagger-oauth.js file. From what I can tell the coffeescript files only generate the swagger-ui.js file. Am I missing something? How should I proceed? Thanks.

[fehguy]

Thanks @bshamblen. The readme is indeed out of date then--if you're going to help contribute support to the 2.0 spec support, please do so in the develop_2.0 branch and try to include tests as possible. It's tough with oauth to do so, but let's do our best. I'll get the readme updated.

[webron]

@bshamblen - we'd love to add this feature, and obviously it's a matter of priorities. I remember you've mentioned a few months ago that you're going to be occupied, and was wondering whether your time has cleared out a bit. We'd love a PR for this feature.

[bshamblen]

@webron - Unfortunately I'm still in full on startup mode right now, and probably won't have any free time for at least another few months. I had to make significant changes to the architecture of the Swagger UI files to get it to work within a Meteor app (not my choice). Since Meteor wraps each js file in its own container I had to parameterize any global variables that were called between files, and basically rewrite the oauth class to make it an object. Meteor also uses a different version of Handlebars, which caused errors when it tried to render the main UI page inside a Meteor template. Since it was such a huge change to the way the code was structured I didn't think you'd want me submitting a PR. But now that I have it working for my particular use case I don't know if I want to mess with it right now.

If case someone else wants to take on adding another flow type, like password, there are a lot of conditional if statements if the oauth file that check to see if the flow is implicit or accessCode. This logic could get out of hand with more flow types, so it should probably be refactored a little to isolate each flow's unique logic.

[webron]

@bshamblen - no worries, you've done a lot already. Thanks for the elaborate input.

[bandtank]

has there been any progress here or does swagger-ui still only support implicit?

[webron]

@bandtank - thanks to @bshamblen we also support the access code flow. At the moment, there's no progress with the password flow though.

[andrassy]

+1

[aidapsibr]

+1

[milanov]

+1

[ismaelgomescosta]

I would like to contribute adding the password flow on Swagger UI, and I would like try to change the authentication screen adding a combobox with the grant types specified by the user.

[fehguy]

Would be greatly appreciated @mundodojava

[ismaelgomescosta]

Which branch I can fork to work?

[BernieN]

+1

[frenchbread]

@bshamblen Would you mind publishing the souse code for modified Swagger UI that could work within Meteor App. We are facing similar issues that you've described. Related issue - #1757.

If you could publish modified source code or even create a separate package for meteor that would be really helpful.

[markwalsh-liverpool]

+1

[jsmusgrave]

+1

[jeancloudvanlang]

+1

[Joe-Palmer]

+1

[isangomar]

+1

[SwiTool]

+1

[Ciantic]

There is already a pull request for this feature: https://github.com/swagger-api/swagger-ui/pull/1853

[frol]

@Ciantic Unfortunately, my PR #1853 is outdated due to a great refactoring in Auth support implementation. Several implementations were already made (#1574 and #1853), but none was ever pushed or even reviewed. I hope @fehguy will implement the support himself since I haven't seen his support in the proposed PRs.

[chumlee007]

+1

[HarelM]

+1 This is open for far too long...

[anshchauhan]

+1

[shishirsharma]

+1

[Misiu]

+1

[loning]

+1

[ntadic]

+1

[Andrew-Mace]

+1

[rifaj]

+1

[rmharrison]

+1

[Ratedev]

i would really like to the swagger-ui support the password flow
+1

[lovemyliwu]

+1

[xperiandri]

Why client_id can be not included into URL?

[xperiandri]

Is this how it works now?
https://github.com/domaindrivendev/Swashbuckle.AspNetCore/issues/326#issuecomment-285814786

[thaihau]

Still not support password flow ?

[mwvdev]

@thaihau We are currently using the password flow using swagger-ui version 2.2.10. See the attached screenshot.

Our security definition in swagger.yaml is:

securityDefinitions:
  applicationoauth:
    type: "oauth2"
    tokenUrl: "http://localhost:8080/internal/api/internal/authentication/token.json"
    flow: "password"
    scopes:
      read: ""
      write: ""

Hope that helps.

[daibertdiego]

After this Authorization, how I can use the access-token in the others Try-out? Because I did the Authorization with success, but in the others requests the Bearer Token is not present.

[chiguawuxi]

After this Authorization, how I can use the access-token in the others Try-out? Because I did the Authorization with success, but in the others requests the Bearer Token is not present.

I'm confronted with the same issue

[shockey]

@daibertdiego @chiguawuxi you should add

security:
- applicationoauth: []

to each operation that you'd like to secure, or at the root level of your OpenAPI document if you'd like to secure the entire API. Replace applicationoauth with whatever name you gave your security definition!