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:comment-tabpanel&focusedCommentId=63984#comment-63984 ] 

Michael Pizzo commented on ODATA-974:
-------------------------------------

Clarify where this is applied; typically to entity container, may also be applied to individual entityset/singleton/perhaps even nav prop?

> 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
>         Environment: Proposal needed for CSD01
>            Reporter: Michael Pizzo
>            Assignee: 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]