-
Notifications
You must be signed in to change notification settings - Fork 76
Assertions for non-JWT tokens, users without access #20
Comments
For completeness, it seems that if I were able to get ahold of the facebook signed_request parameter from the login, I would be able to use that directly with the existing JWT structure, excepting (3), which could still benefit from the callback. Unfortunately, I don't seem to be able to get that token from the login library my mobile developer is using. |
Any thoughts here? |
Sorry, I'm not sure I understand this scenario. Can you include the request that would be made to the rack-oauth2-server instance in this flow (step 2 above)? Maybe that will help me understand..... |
Sure, the request looks like this:
It serves the same purpose as sending the signedRequest from Facebook, except in this case the Facebook wrapper I have access to doesn't make the signedRequest available, so I only have the accessToken. It is what is sent in the assertion field, validated by the server, which then issues its own credentials if the accessToken is valid and the user is known to the server. |
While I see that what you're suggesting is a hook to allow users of rack-oauth2-server to add support for arbitrary assertion types via configuration (which is a good idea), your Facebook example doesn't seem very secure to me. Obviously if you want to use that approach in a real app that's your call.... @assaf, any issues with this feature? If not I'll merge it in. |
Brian, I'd like to understand more why it's not secure, provided I send the On Mon, Jun 4, 2012 at 2:31 PM, Brian Ploetz <
|
No issue that I can see. On Monday, June 4, 2012 at 11:31 AM, Brian Ploetz wrote:
|
@pacovell can you send a formal pull request from a topic branch in your repo containing only this change? |
@pacovell I'm looking exactly for this kind of assertion feature, do you have an example on how to use them? Thanks |
Use Case:
oauth2-provider (https://github.com/songkick/oauth2-provider) covers this use-case by having an assertion handler:
[Edited]: My thought is to do the same thing:
This totally bypasses the register_issuer configuration, which may be seen as a Bad Thing, so please let me know your thoughts.
To avoid mucking anything up with JWT tokens, I'll skip the assertion_handler in this case, but it may be useful later, as I can't see right now how a JWT token would be associated with an local identity unless the original creator knows our identity data. Maybe I am missing something?
Thoughts, better ways to handle, or other comments?
The text was updated successfully, but these errors were encountered: