Hello everybody, again.
This is just me pushing a random idea, but what if you specified that
clients could ask for access token invalidation by making a DELETE
request to the token endpoint?
Bart Wiegmans
___
OAuth mailing list
Hi Bart,
I think this would be a truly RESTful approach. The group discussed this topic
several months ago and consensus was to use another endpoint for token
revocation (== deletion). Pls. take a look onto
http://tools.ietf.org/html/draft-lodderstedt-oauth-revocation-02.
regards,
Torsten.
Thanks Buhake,
Yes, this seems to be a bug in the draft.
We're preparing a new update in the next couple of weeks,
and will fix this one.
Thanks again.
/thomas/
__
-Original Message-
From: Buhake Sindi [mailto:buh...@googlemail.com]
Sent:
I'm having trouble finding information on how to do 2leg authentication
with OAuth 2.0. Does it even support it?
Thanks
Brian
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
This diagram may be out of date, but I found it useful early on to understand
the multiple flows and legs of OAuth.
http://www.independentid.com/2011/03/oauth-flows-extended.html
The question of legs (or parties as some prefer) depends on what you have and
what you need.
Take a look at
This functionality can be implemented in two main ways:
1. Using the client credentials flow to get an access token, then using
the protocol as usual
2. Just using the Bearer (over SSL) or MAC token schemes without the rest
of OAuth
EHL
From: oauth-boun...@ietf.org
Or using the SAML or JWT grants to get an access token, then using the
protocol as usual.
On Tue, Nov 29, 2011 at 1:06 PM, Eran Hammer-Lahav e...@hueniverse.com wrote:
This functionality can be implemented in two main ways:
1. Using the client credentials flow to get an access token,
Maybe I'm making this harder then it should be.
Here is the situation: Site A and B both trust each other. Site A needs
to update user information at site B.
With OAuth 1.0 Site A would use it's consumer key and secret to sign the
update call to Site B (no access token involved). Only one
Both MAC and Bearer work in this setup, just think of them as HMAC-SHA-1 and
PLAINTEXT in OAuth 1.0. In Bearer, your token is the client secret and in MAC,
the client secret is the key.
EHL
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Brian
Hawkins
Sent: Tuesday,
This isn't really OAuth, this is a trust relationship between A and B. OAuth
is providing an avenue for the user to approve access because the user owns the
resource. That's why this doesn't really fit what you are trying to do.
You could use MAC signatures to secure the transactions with a
MAC would be more appropriate in my opinion for this.
From: Eran Hammer-Lahav e...@hueniverse.com
To: Brian Hawkins br...@lingotek.com; oauth@ietf.org oauth@ietf.org
Sent: Tuesday, November 29, 2011 12:38 PM
Subject: Re: [OAUTH-WG] 2 Leg with OAuth 2.0
11 matches
Mail list logo
