But... this proposal issues id_tokens. Is this proposal stupid for doing so, or
does Microsoft not actually implement it as written?
Also, I can't find any mention of this in your docs. Can you point us to it?
And doesn't Microsoft implement OpenID Connect already? You guys joined the
OIDC inte
>> IMHO OAuth2 is becoming much bigger... Take the client credentials grant.
People are using it today in the traditional scenarios, because OAuth2
tokens have good security properties.
Agreed.
-gil
___
OAuth mailing list
OAuth@ietf.org
https://www.ie
Hi,
On 23/07/14 20:28, Gil Kirkpatrick wrote:
The RFCs 6749 and 6750 are a good place to start.
http://tools.ietf.org/html/rfc6749 and http://tools.ietf.org/html/rfc6750.
The first thing to understand is that OAuth2 targets a very specific use
case of a user authorizing an application (like Twi
Is it said anywhere that ALL grant types MUST use Section 5.1 responses?
Each grant type references Section 5.1, and "access token request" is only
defined in the context of the defined grant types. Section 2.2 doesn't talk
about the request or response format.
Le 23 juil. 2014 21:32, "Nat Sakimura
Is it? Apart from the implicit grant that does not use token endpoint, all
other grant references section 5.1 for the response, i.e., all shares the
same response.
2014-07-23 15:18 GMT-04:00 Thomas Broyer :
> I hadn't realized the JSON response that requires the access_token field
> is defined p
Section 5.1 defines _the_ token endpoint response for all grant types. The
assumption always was that different grant types allow the client to exchange
different authz grants into an access token (and probably a refresh token).
> Am 23.07.2014 um 15:18 schrieb Thomas Broyer :
>
> I hadn't rea
I hadn't realized the JSON response that requires the access_token field is
defined per grant_type, so I'd be OK to "extend the semantics" as in the
current draft.
That was actually my main concern: that the token endpoint mandates
access_token; but its actually not the case.
Le 23 juil. 2014 20:46
Thanks again for the review and feedback, Kathleen. I added privacy
considerations, as discussed on this thread, to the assertion drafts and
published them this morning.
On Sun, Jul 20, 2014 at 6:18 AM, Kathleen Moriarty <
kathleen.moriarty.i...@gmail.com> wrote:
> Thanks, Brian. That looks g
Thanks Takahiko. Good analysis.
2014-07-23 14:12 GMT-04:00 Takahiko Kawasaki :
> Hello,
>
> (1) RFC 6749
> grant_type=authorization_code
> response={"access_token":...}
>
> (2) OpenID Connect Core
> grant_type=authorization_code
> response={"access_token":..., "id_token":...}
>
> (3) Cur
I agree with John that overloading response_type @ authz endpoint is a bad
idea. It completely changes the semantics of this parameter. NOTE: what I
was proposing was not this parameter, but a new parameter response_type @
token endpoint.
I also think overloading grant_type is a bad idea since it
New versions of all three OAuth related assertion documents (listed below)
have been published with Privacy Considerations added to each. The request
for Privacy Considerations came out of AD review and, with this update, all
known issues/comments have now been addressed.
Assertion Framework for O
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Web Authorization Protocol Working Group of
the IETF.
Title : SAML 2.0 Profile for OAuth 2.0 Client Authentication
and Authorization Grants
Authors
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Web Authorization Protocol Working Group of
the IETF.
Title : JSON Web Token (JWT) Profile for OAuth 2.0 Client
Authentication and Authorization Grants
Aut
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Web Authorization Protocol Working Group of
the IETF.
Title : Assertion Framework for OAuth 2.0 Client
Authentication and Authorization Grants
Authors
Hello,
(1) RFC 6749
grant_type=authorization_code
response={"access_token":...}
(2) OpenID Connect Core
grant_type=authorization_code
response={"access_token":..., "id_token":...}
(3) Currently being discussed
(3)-1
grant_type=authorization_code
response_type=id_token (a new p
FYI, the individual submission draft
http://tools.ietf.org/html/draft-jones-oauth-token-exchange describes adding
something analogous to WS-Trust token exchange to OAuth 2.0. That will be
discussed at the OAuth working group meeting tomorrow.
If we use the token endpoint then a new grant_type is the best way.
It sort of overloads code, but that is better than messing with response_type
for the authorization endpoint to change the response from the token_endpoint.
That is in my opinion a champion bad idea.
In discussions developin
The RFCs 6749 and 6750 are a good place to start.
http://tools.ietf.org/html/rfc6749 and http://tools.ietf.org/html/rfc6750.
The first thing to understand is that OAuth2 targets a very specific use case
of a user authorizing an application (like Twitter) access to resources they
own (like p
The "response type" of the token endpoint is controlled by the value of
the parameter "grant_type". So there is no need to introduce a new
parameter.
wrt to a potential "no_access_token" grant type. I do not consider this
a good idea as it changes the semantics of the token endpoint (as
alread
IMHO, changing the semantics of "response_type" @ authz endpoint this way
is not a good thing.
Instead, defining a new parameter "response_type" @ token endpoint, as I
described in my previous message,
probably is better. At least, it does not change the semantics of the
parameters of RFC6749.
N
It's only "not using the token endpoint" because the token endpoint copy-pasted
and renamed the authentication endpoint.
-- Justin
On Jul 23, 2014, at 9:30 AM, Thomas Broyer
mailto:t.bro...@gmail.com>> wrote:
Except that these are about not using the Token Endpoint at all, whereas the
curren
No, I mean response_type=none and response_type=id_token don't generate a
code or access token so you don't use the Token Endpoint (which is not the
same as the Authentication Endpoint BTW).
With response_type=code_for_id_token, you get a code and exchange it for an
id_token only, rather than an ac
Except that these are about not using the Token Endpoint at all, whereas
the current proposal is about the Token Endpoint not returning an
access_token field in the JSON.
On Wed, Jul 23, 2014 at 4:26 PM, Mike Jones
wrote:
> The response_type “none” is already used in practice, which returns no
Fair enough. It is revealing to hear that it is OK to have no access token
after all as OAuth. (Though, in the next rev., I suppose the text needs to
be fixed.)
Then, like Justin says, it probably is just a matter of defining an
'response_type' extension parameter to the token endpoint.
It is prac
The response_type “none” is already used in practice, which returns no access
token. It was accepted by the designated experts and registered in the IANA
OAuth Authorization Endpoint Response Types registry at
http://www.iana.org/assignments/oauth-parameters/oauth-parameters.xml#endpoint.
The
Yes. This is why it has to be discussed in the IETF.
Phil
@independentid
www.independentid.com
phil.h...@oracle.com
On Jul 23, 2014, at 9:43 AM, Nat Sakimura wrote:
> Reading back the RFC6749, I am not sure if there is a good way of suppressing
> access token from the response and still be
Reading back the RFC6749, I am not sure if there is a good way of
suppressing access token from the response and still be OAuth. It will
break whole bunch of implicit definitions like:
authorization server
The server issuing access tokens to the client after successfully
authenticating
The draft is very clear.
Phil
> On Jul 23, 2014, at 0:46, Nat Sakimura wrote:
>
> The new grant type that I was talking about was
> "authorization_code_but_do_not_return_access_nor_refresh_token", so to speak.
> It does not return anything per se, but an extension can define something on
>
I am pretty familiar with the WS-* and SOAP Web Services world. At the
moment I'm trying to understand which features are available in the OAuth
2.0 world.
1) SAML tokens: This access token in OAuth 2.0 - is it similar to what SAML
tokens are for?
2) STS: Is an OAuth 2.0 Authorization Server the
29 matches
Mail list logo
