Support for OpenAPI 3.0, specifically additional security schemes / JWT Bearer

[chorsnell]

Not strictly an issue, more of a question, but when will swagger-ui have support for OpenAPI 3.0?

Specifically use of the additional security schemes for JWT + Bearer as per https://github.com/OAI/OpenAPI-Specification/blob/OpenAPI.next/versions/3.0.md#securitySchemeObject

Currently there are workarounds such as using api_key and appending Bearer before the token, but this is a bit of a pain / feels hacky.

Additionally is there a way to set one of the end points to take the response, eg the Bearer token, and then use that in subsequent requests without having to manually copy and paste the token into swagger-ui?

[fehguy]

You should see an announcement almost any day now :)

[chorsnell]

@fehguy oh wow, how's that for a quick response!! :)

Any chance there is going to be something usable in the next week or so? As I'm literally on the verge of starting a fairly large API build and it would be lovely to use it

[shockey]

@poppahorse, see #3083, #3338, and swagger-api/swagger-editor#1376 if you'd like to take a peek at how OAS3 is coming along. There's information in the branches on where to find the code if you'd like to play with it, but I caution you against using that code in a production deployment of UI or Editor.

Note that the new security and Try-It-Out features are not implemented (or scoped out) yet - but static rendering is pretty much there, and editing has most of the 2.0 creature comforts, except for validation.

OAS3 has a Link construct that we're planning to use in the UI to allow information from one operation execution to be mapped to parameter inputs in another operation... but I'm not sure that's exactly what you're asking for.

There's a proposal for a request/response interceptor in #2793 that would allow you to listen for a response from a magic endpoint. From there, as a workaround, you could grab the Bearer token out of the response and feed it into the UI using ui.authActions.authorize() as described in #3318 (comment). There's discussion for a more formal authorization interface in #2915.

Hopefully this gives you some jumping-off points for your use case. Please chime in on the linked tickets if you have anything to add to the conversation!

[chorsnell]

thanks @shockey I will have a look :) ta for all the references