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=64268#comment-64268 ] 

Michael Pizzo edited comment on ODATA-974 at 11/10/16 5:45 PM:

Issue: scope names may not be valid odata identifiers; could make scopes a collection of objects where the objects have name and description properties.

was (Author: mikep):
Issue: scope names may not be valid odata identifiers

> 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

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