Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use of empty scopes in OAuth2 security #15

Closed
tedepstein opened this issue Apr 5, 2019 · 4 comments
Closed

Use of empty scopes in OAuth2 security #15

tedepstein opened this issue Apr 5, 2019 · 4 comments

Comments

@tedepstein
Copy link

Hi @jdegre,

A quick question about the use of empty OAuth scopes in TS29122_AsSessionWithQoS.yaml,
TS29122_ChargeableParty.yaml and some others:

Does the absence of scopes mean that authorization MUST NOT be dependent on scope?

Or does it mean that the API implementation can define its own scopes within the OAuth security scheme, and specify its own scope requirements on the API operations that use that scheme?

I'm asking because I've opened a pull request in the OpenAPI Specification to explicitly allow empty scopes in Security Scheme Object and OAuth Flow Object, and to clarify the meaning in cases where scopes are specified as empty.

Background

In working with the 5GC OpenAPI documents, our editor flags an error on the empty array specified as the scopes value in the Security Requirement Object:

security:
  - {}
  - oAuth2ClientCredentials: []

The array normally holds a list of scopes defined in the OAuth Security Scheme, but the oAuth2ClientCredentials scheme has an empty object as the scopes value:

  securitySchemes:
    oAuth2ClientCredentials:
      type: oauth2
      flows:
        clientCredentials:
          tokenUrl: '{tokenUrl}'
          scopes: {}

By my count, there are 15 APIs that are defined this way. For reference, here are a few of them:

  • TS29122_AsSessionWithQoS.yaml
  • TS29122_ChargeableParty.yaml
  • TS29122_CpProvisioning.yaml
  • TS29122_DeviceTriggering.yaml

The OpenAPI 3.0.2 specification says that scopes is required in an OAuth Flow Object within an oauth2-typed Security Scheme Object. It doesn't explicitly say that the object value must define at least one scope, and therefore must not be empty. But we interpreted the fact that it's required to mean that it's required to be non-empty.

In fact, KaiZen Editor tolerates the empty scopes object, but it flags an error on the corresponding empty scopes array in the Security Requirement Object.

It turns out that an empty scopes object is allowed in the Security Scheme Object, and a corresponding empty array is allowed in the Security Requirement Object. This is described in a closed issue #513 on the OAS spec project. I think the spec could be explicit about this, so I have submitted pull request #1888 to address this.

And we will fix this issue in KaiZen OpenAPI Editor so we can work with the 5GC documents.

@jdegre
Copy link
Owner

jdegre commented Apr 9, 2019

@tedepstein, the intention is to mean that no specific scope is required.
I noticed that the KaiZen editor currently flags this as an error, so I'm glad that this issue is being addressed in the tool. Thanks!

@tedepstein
Copy link
Author

Thanks for clarifying, @jdegre. Next patch release of KaiZen Editor should include this fix.

@tedepstein
Copy link
Author

tedepstein commented Apr 17, 2019

Update: KaiZen OpenAPI Editor now allows empty scopes map and empty Security Requirements object as described. All of the 5GC APIs now validate correctly.

@jdegre
Copy link
Owner

jdegre commented Apr 17, 2019

Yeah, I was eagerly waiting for it, so I updated the Editor earlier today, and checked the APIs; yeap, I saw that all constructs, previously flagged as errors, now pass the syntax checks correctly. Thanks for the update, and keep up the great work!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants