You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Feb 17, 2024. It is now read-only.
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.0settings:
authorizationUri: https://example.com/futile_constraint/but_why?authorizationGrant=code#is-not-the-case-hereaccessTokenUri: https://api.meteoplus.net/1/oauth2/authenticationauthorizationGrants: [ 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.
The text was updated successfully, but these errors were encountered:
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.
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:
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
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.
The text was updated successfully, but these errors were encountered: