OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

odata message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: [OASIS Issue Tracker] (ODATA-974) Flesh out recommendations around OAuth support in OData


     [ https://issues.oasis-open.org/browse/ODATA-974?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Michael Pizzo updated ODATA-974:
--------------------------------

    Description: 
Today there is no interoperable way to consume an OData service that supports authentication.  We recommend, in Chapter 20, the use of basic auth (which is more interoperable, but less secure than something more common like oauth).

If we could provide information, perhaps through a vocabulary, that would describe the authentication flow of the service, it would hugely improve interoperability across authenticated services.

One option would be to advertise in $metadata action annotated as an authorization action, with (well-known) parameters for the information it needs (clientid, secret, scope, etc.). I.e., when the client invokes the "Login" action with the appropriate parameter values, the service would build the authentication url using the parameter values with a redirect url to itself, redirect the client to that authentication url, and then wait to be called back on its own supplied redirect url.

Note that Swagger/OneAPI defines some auth flow here, but it is unclear whether this is would work for all cases (the only listed auth types are "basic", "apiKey", and "OAuth2" -- OAuth1, at least, is absent) https://github.com/OAI/OpenAPI-Specification/blob/master/versions/2.0.md#securityDefinitionsObject


  was:
Today there is no interoperable way to consume an OData service that supports authentication.  We recommend, in Chapter 20, the use of basic auth (which is more interoperable, but less secure than something more common like oauth).

If we could provide information, perhaps through a vocabulary, that would describe the authentication flow of the service, it would hugely improve interoperability across authenticated services.

One option would be to advertise in $metadata action annotated as an authorization action, with (well-known) parameters for the information it needs (clientid, secret, scope, etc.). The service could then use that to build a URL to an authentication service and redirect the client to that URL, providing a URL to itself as the redirect URL

Note that Swagger/OneAPI defines some auth flow here, but it is unclear whether this is would work for all cases (the only listed auth types are "basic", "apiKey", and "OAuth2" -- OAuth1, at least, is absent) https://github.com/OAI/OpenAPI-Specification/blob/master/versions/2.0.md#securityDefinitionsObject



> Flesh out recommendations around OAuth support in OData
> -------------------------------------------------------
>
>                 Key: ODATA-974
>                 URL: https://issues.oasis-open.org/browse/ODATA-974
>             Project: OASIS Open Data Protocol (OData) TC
>          Issue Type: Bug
>          Components: OData Protocol
>    Affects Versions: V4.0_ERRATA03
>            Reporter: Michael Pizzo
>             Fix For: V4.01_WD01
>
>
> Today there is no interoperable way to consume an OData service that supports authentication.  We recommend, in Chapter 20, the use of basic auth (which is more interoperable, but less secure than something more common like oauth).
> If we could provide information, perhaps through a vocabulary, that would describe the authentication flow of the service, it would hugely improve interoperability across authenticated services.
> One option would be to advertise in $metadata action annotated as an authorization action, with (well-known) parameters for the information it needs (clientid, secret, scope, etc.). I.e., when the client invokes the "Login" action with the appropriate parameter values, the service would build the authentication url using the parameter values with a redirect url to itself, redirect the client to that authentication url, and then wait to be called back on its own supplied redirect url.
> Note that Swagger/OneAPI defines some auth flow here, but it is unclear whether this is would work for all cases (the only listed auth types are "basic", "apiKey", and "OAuth2" -- OAuth1, at least, is absent) https://github.com/OAI/OpenAPI-Specification/blob/master/versions/2.0.md#securityDefinitionsObject



--
This message was sent by Atlassian JIRA
(v6.2.2#6258)


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]