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,
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,
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
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
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,
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
