Add bearer auth scheme as the default security scheme

[jannyHou]

Suggestion

After story #4380 finished, we can add a security spec enhancer to have the bearer auth scheme as the default(or built-in) security scheme. So that explorer has the authorization dialog for people to inject the token per request.

Use Cases

Add an OAI enhancer that add the following spec into OpenAPI spec generated in the rest server:

"components": {
    "securitySchemes": {
      "jwt": {
        "type": "http",
        "scheme": "bearer",
        "bearerFormat": "JWT"
      }
    },

Examples

See the screenshot in https://loopback.io/doc/en/lb4/Authentication-Tutorial.html#specifying-the-security-settings-in-the-openapi-specification

Acceptance criteria

• add a security spec enhancer to have the bearer auth scheme as the default(or built-in) security scheme

[jannyHou]

@dougal83 ah, true jwt is more accurate 👍

[emonddr]

@dougal83 , @jannyHou ,

Regarding the comment

Good idea to add to develop the schema. Personally I'd be more specific and name it jwt rather than bearerAuth.

Exactly what are we talking about here?

The title of the github issue :
Add bearer auth scheme as the default security scheme ?

Or

in https://loopback.io/doc/en/lb4/Authentication-Tutorial.html#specifying-the-security-settings-in-the-openapi-specification ?

Because the OpenAPI spec examples above (not the screen cap) do not have
bearerAuth

Please clarify.

Thanks

:)

[dougal83]

Hey @emonddr

This issue is to enhance the openApi spec by adding to components.

I've just jumped on it to suggest a name change from bearerAuth to jwt. I'm aware that bearerAuth is currently in use so if consensus for change is found then all instances would need to be updated. The bearerFormat property is just arbitrary and so using jwt as security scheme name would be better IMO.

Considering the top level security property of openapi spec, it would be easier to grasp the nature without looking up the schema:

  "security": [
    {
      "jwt": []
    }
  ],

Really me nitpicking atm.

[dhmlau]

@strongloop/loopback-next @strongloop/loopback-maintainers @mschnee

Call for contribution:
This task is part of the epic "Allow out-of-box token based authentication in API Explorer" , that we wish to get it done in 2020Q1. If you're interested in working on it, please leave a message here and we'll assign it to you. We'll take the first person who responds. 😬

Happy contributing!

[dougal83]

@jannyHou For clarification, is this story to add jwt strategy /w enhancer to base project generator template?

[dougal83]

I have a busy March so unassigned in case someone else wishes to help in the meantime.

[dhmlau]

@jannyHou @raymondfeng, could you please clarify? Thanks.

[jannyHou]

after having the jwt authentication component extracted in examples/access-control-migration, I am thinking refactor the strategy in this example to extend the enhancer and provide jwt auth spec by default.

I am not sure if @raymondfeng still wants to have the authorize button enabled for explorer for ANY loopback app w/ or w/o authentication enabled.

cc @raymondfeng WDYT?

[dhmlau]

@jannyHou, is it possible to show/hide the authorize button based on whether the app has authentication enabled?
btw, what's the behavior in LB3?

[jannyHou]

I created a LB3 app, disabled the auth system in boot script

// server.enableAuth();

The token field still exists in explorer so I believe it's always provided out of box in LB3.

[dhmlau]

How about we always show the authorize button, as the first iteration? It's better to always show the button/field than always hide!

cc @raymondfeng

[jannyHou]

created PR in #5493

[dhmlau]

Closing as done.