OAuth Playground(grant-oauth.herokuapp.com)
grant-oauth.herokuapp.com
OAuth Playground
https://grant-oauth.herokuapp.com/
9 comments
Code: https://github.com/simov/grant
Can't get in, application error
Hi, this one was just to showcase my OAuth express middleware, which in turn uses a code from Mashape's guardian auth proxy.
Currently all of these OAuth flows requires human interaction, at least for the first time. I think the OAuth specs guys are working on a digital signature that will allow multiple provider sign on in future.
Currently all of these OAuth flows requires human interaction, at least for the first time. I think the OAuth specs guys are working on a digital signature that will allow multiple provider sign on in future.
I'm getting an application error.
You got "HN hug of death".
It's down now but here are some other oauth tools I use and built:
foauth.org
Token generator: https://www.runscope.com/oauth_tool
foauth.org
Token generator: https://www.runscope.com/oauth_tool
I would love to see this become the new Todo-list.
I'm not sure I get your reasoning... The todo list is usually an example for an application (though somewhat trivial) that exercises a given ui framework.
What I wouldn't mind seeing is this pushed out into a larger provider, so that you can have one user/profile in your application connected to one or more oauth and/or openid accounts. By default only asking for a real name (if available) and authenticated email address. Combined with an option for a username/password and optional 2fa key as an authentication method.
I think such a generic login system/screen would be far more useful to most people who are going to use an application that uses authentication from other systems. And allow for people that have more than one authentication.
As for the todo-list example, I was thinking of creating a relatively simple chatbox app with flux/react (yahoo/fluxible-app), including such authentication as a baseline. I feel that that would be a useful example for a lot of people.
The flip-side is I've been using koa lately over express (requiring node >= 0.11.x). Maybe a wrapper for express modules to koa results... in this case, thunkifying the module, and passing in the req/res should be enough, the callback (next) won't be called if handled internally. Though uncertain what this adds to req/res to mirror on the koa context.
What I wouldn't mind seeing is this pushed out into a larger provider, so that you can have one user/profile in your application connected to one or more oauth and/or openid accounts. By default only asking for a real name (if available) and authenticated email address. Combined with an option for a username/password and optional 2fa key as an authentication method.
I think such a generic login system/screen would be far more useful to most people who are going to use an application that uses authentication from other systems. And allow for people that have more than one authentication.
As for the todo-list example, I was thinking of creating a relatively simple chatbox app with flux/react (yahoo/fluxible-app), including such authentication as a baseline. I feel that that would be a useful example for a lot of people.
The flip-side is I've been using koa lately over express (requiring node >= 0.11.x). Maybe a wrapper for express modules to koa results... in this case, thunkifying the module, and passing in the req/res should be enough, the callback (next) won't be called if handled internally. Though uncertain what this adds to req/res to mirror on the koa context.
I disagree - there is no way to securely store security tokens (both the client secret and the access token) in client side code.
There should always be a server side proxy so that this data doesn't leak
There should always be a server side proxy so that this data doesn't leak
Thanks! This would really save time to directly test notable api calls. Specially in a RAD environment
oauth.io