You can actually issue a JWT as an access token (since OAuth doesn't
care about the token format), so in this case the JWT would be used to
get access to the widget provider. The JWT would be a pre-signed bearer
token that the provider would know how to check.
-- Justin
On 9/2/2011 6:50 PM,
Very nice. The token format is straightforward, and not terribly unlike our
current "proprietary" approach (we use CSV instead of JSON, but at the end of
the day it's a bunch of fields and HMAC). Even if all we did was swap out our
current format for JWT, I think that would be a big win.
So,
JWT is designed to be used with OAuth and openID Connect.
There is a IETF WG being created to standardize the signing and encryption for
JWT and other JSON tokens.
John B.
> A new IETF working group has been proposed in the Security Area. The
> IESG has not made any determination as yet. The
JWT is definitely not at odds with OAuth. I guess you could say JWT
is potentially complementary in a number of ways (they can be used
together but don't need to be). Though I'm not aware
of any spec work around it, I suspect many will chose to use JWT as a
bearer access token format. JWTs can a
On Wednesday, August 31, 2011 02:05:58 PM George Fletcher wrote:
> You could also use a signed JWT returned by the resource owner (web
> site) to be presented to the resource server (widget provider) that the
> resource server can validate (e.g. verify the signature). The JWT can
> contain scopes,
You could also use a signed JWT returned by the resource owner (web
site) to be presented to the resource server (widget provider) that the
resource server can validate (e.g. verify the signature). The JWT can
contain scopes, expiry time, etc as needed. If the widget provider needs
to access se
Thanks Justin. I tend to agree that this is probably not a 2-legged issue,
and that there is likely a better fitting arrangement in the OAuth 2.0 system.
I've thought about this some more, and, especially given that the website and
widget provider are separately-owned entities, maybe the roles
This description actually sounds a lot like the user-agent flow (aka,
"implicit authorization grant") in OAuth2 more than it does a true
two-legged system. The user is still there, and there's still a client
and protected resource, it's just that they're fairly tightly tied.
When using the implici
I tried to help Justin off-list, but it would be nice to have a FAQ
somewhere that shows developers how to translate from OAuth 1.1 to OAuth
2.0, even just conceptually (as in, "they got rid of the legs, how do I
do two-legged auth in OAuth 2.0?!?").
On 8/26/11 5:04 PM, Justin Karneges wrote:
> Hi
Hi folks,
I currently use a proprietary token approach to provide authentication to a
browser widget, and I wonder if OAuth could be used to replace it.
Here's how the system currently works:
- website supports authenticated users (happens via username/password form)
- website and widget pro
10 matches
Mail list logo
