Better Security Definitions for more granularity

[Diliz]

Hello there,

First of all, thanks for your work 👍

---

Context

So, this times I got to add scopes verification and all to different endpoints security (paths).

I want to have multiple scopes for a same securityDefinition to be able to access one route, but I just want to check if the token have at least one of this scopes.

It could be really better if the scopes definition can be an object, with more specifications possibilities, let me explain better.

Current Specs

What we actually have:

securityDefinitions:
  oauth2-testing:
    ...
    scopes:
      - write
      - read

paths:
  /test:
    get:
      security:
        oauth2-testing:
          - read
          - write

With this you must have the scope read and write to access the /test path. To make this scopes optionnals, this should do the trick:

securityDefinitions:
  oauth2-read:
    ...
    scopes:
      - read
  oauth2-write:
    ...
    scopes:
      - write

paths:
  /test:
    get:
      security:
        oauth2-read:
          - read
        oauth2-write:
          - write

Current Specs Problem

As you can see, this is not the more convenient way to do this, if you want to have at least one of the scopes needed to access the /test path, this is not so good, even on swagger-ui, this is making multiple securityDefinitions for one same authentification rule... For just having multiple scopes for one route.

---

Specs Refacto Idea

First Idea

So, I think making it something like:

securityDefinitions:
  oauth2-testing:
    ...
    scopes:
      read:
        required: False
      admin:
        required: False
      another_scope:
        required: False

paths:
  /test:
    get:
      security:
        oauth2-testing:
          read:
            required: False
          admin:
            required: False
          another_scope:
            required: True

Second Idea

securityDefinitions:
  oauth2-testing:
    ...
    oneOf: True
    scopes:
      - read
      - admin
      - another_scope

paths:
  /test:
    get:
      security:
        oauth2-testing:
          oneOf: True
          scopes:
            - read
            - admin
            - another_scope

Conclusion

I know this is maybe not the best solution here, but it can't be cool to think about making the security options more flexible and more readable in case I want one mandatory scope and at least one of the others, something like that is actually not possible with the current specs.

I think it could be better to go with scopes being an array of objects (making the scope checks more granular for one route, can add other rules in it later...)

---

Don't hesitate to tell me if it's something wrong and why, actually maybe misunderstand something about the whole security specs :)

Thanks for reading

[kdefives]

Totally agree, it could be very useful! 👍
As a workaround, today i am doing this:

components:
  securitySchemes:
    oauth2-testing:
      type: oauth2
      flows:
        implicite:
           scopes:
               - profile:read:birthdate
               - profile:read:name

paths:
  /test:
    get:
      security:
        - oauth2-testing:
           - profile:read:birthdate
        - oauth2-testing:
          - profile:read:name

I need this because my endpoint /test have to be reachable by a user A who own profile:read:birthdate scope only in order to get birthdate but do not need the name. An another user B who own profile:read:name scope only because he can only see the name.

Why i need this? Because i have to implement the concept of RBAC in my code in order to display claims (here birthdate and name) depending of scope owned by the user inside his JWT token.

Note: Example above is simple, but in my case i have a lot of different claims with multiple scopes. I cannot imagine to create a separate endpoint for each claims.

[lusoalex]

Hello,
I do agree with the above comments.
Just looking to the openid connect default scopes (profile, email, address, phone), not all are necessary when fetching the user information. I guess this behavior is needed in other ReST endpoints.

Regarding the settings, here is another suggestion on how to handle it:

securityDefinitions:
  oauth2-testing:
    ...
    #default is allOf
    scopes-policy: oneOf 
    scopes:
      - read
      - admin
      - another_scope