Skip to content
This repository has been archived by the owner on Feb 17, 2024. It is now read-only.

[04] securitySchemes.settings contradiction / too restrictive? #38

Open
Philzen opened this issue Apr 27, 2014 · 2 comments
Open

[04] securitySchemes.settings contradiction / too restrictive? #38

Philzen opened this issue Apr 27, 2014 · 2 comments

Comments

@Philzen
Copy link
Contributor

Philzen commented Apr 27, 2014

Sincerest apologies if i'm mistaking / overlooking something in the spec here whilst my eyes glare over after days of cross-reading specs, slide presentations, "REST"ful articles trying to come up with a sensible prototype - but i kinda bumped into this:

# ...
securitySchemes:
 - oauth_2_0:
    description: |
        The IWK Weather API supports OAuth 2.0 for authenticating all API requests.
    type: OAuth 2.0
    settings:
      authorizationUri: https://example.com/futile_constraint/but_why?authorizationGrant=code#is-not-the-case-here
      accessTokenUri: https://api.meteoplus.net/1/oauth2/authentication
      authorizationGrants: [ credentials ]
# ...

In this example the api only implements Oauth 2.0 section 4.4, which in my understanding is "1-legged" authentication, not requiring any authorization endpoint redirect and such. Same with section 4.3

At the same time, RAML Section 08_security.md puts a constraint on the existence of securitySchemes.settings.authorizationUri.

This is unexpected behaviour or a logical contradiction - again, pls forgive me if i overlooked s.th. blantantly here.

NB: I acknowledge the fact that Oauth2.0 is a particularly hard example to get right in this trait-like declaration - definition of 'right' or at least 'better' in my possibly opinionated view means: one ideally never ends up writing s.th. like

this is a required parameter, when we are in the xy flow context. Don't use when parameter z1 is set

at least this "itches" somehow - apart from that: so far it's been just pure ❤️ for the spec and it's ecosystem! Thanks so much for pulling this together.

@mzizzi
Copy link

mzizzi commented Aug 7, 2014

Agreed. I believe that the spec is a bit too restrictive here as well. As far as I can tell, the spec doesn't play nicely with one legged OAuth since authorizationUri is required.

@quilicicf
Copy link

+1

As far as my understanding of OAuth 2 goes, the following is true:

Flow Authorization URL required ? Token URL required ?
Code
Token
Owner
Credentials

But when I generate a RAML with one of the non-required URL missing, I get a warning from RAML JS parser.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Development

No branches or pull requests

4 participants