Should implementors of OAuth libraries enforce that an assertion belongs to
a particular client?
E.g.: if there are two clients cA and cB, and cA gets issued an assertion
foo, can cB then use foo to obtain an access token at the token endpoint?
thanks
lvh
_
Hi
2.1. Client Password Credentials
First example:
POST /token HTTP/1.1
Host: server.example.com
Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
Content-Type: application/x-www-form-urlencoded
grant_type=authorization_code&client_id=s6BhdRkqt3&code=i1WsRn1uB1&
redirect_uri=https%3A%2F%2Fclien
Hi,
In the most recent draft version of the spec, section 2.1. Client Password
Credentials, the following example request is given:
POST /token HTTP/1.1
Host: server.example.com
Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
Content-Type: application/x-www-form-urlencoded
grant_type=authoriz
Whoops, turns out we were just abusing scope (ie not in the SAML sense).
Sorry; my bad.
Laurens
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
Hey,
We have a use case for a scope that's more fine-grained/flexible than
what you could explain in a set of space-delimited keywords. We would
like to encode things like the precision with which some data can be
accessed, and the scope sounds like the reasonable place to do that.
Of course we
B
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
On Thu, Jul 8, 2010 at 11:53 AM, Kris Selden wrote:
> The refresh token is key to separating concerns of the protected resource
> from the auth server.
>
> I think this is succinctly explained the original rationale (refresh token =
> refresh secret):
> http://wiki.oauth.net/ScalableOAuth#Append
Just pitching in as someone writing something that might want a
refresh token but *really* doesn't understand why he'd need them. They
make very little sense to me; why not just make the token that allows
you to access a protected resource last longer? Use case: we've got
protected resources that g
Um, this is reasonably common Mailman behavior (admittedly less common
than the alternative), and the signup page warns you about it:
You may enter a privacy password below. This provides only mild
security, but should prevent others from messing with your
subscription. Do not use a valuable passw
