Hi Alan,
We are actually building using the exact same stack. At the moment we are building out a web application that will be initially at least be the only client (we will move to mobile etc) Because we are only looking at trusted apps at the beginning the full work flow for this hasn't been outlined, what i mean is we haven't bothered initially with implementing other strategies for oAuth that will allow for third party apps we are only concerning ourselves with trusted client Auths. We have done a few spikes as even the the overall flows are simply to view and visualise the actual protocol itself can be complex. We have currently settled (and someone mentioned this above) on using Auth2orize with passport.js based strategies. As we are doing this based on a trusted app we are using the Resource Owners Pasword Credentials which eliminates the dialog for us as means we can use a traditional login form to authenticate the user and return a bearer token to authorise them moving forwards. If we we were working with 3rd parties who wanted access to our API then we would use one of the other flows so that the username and password do no touch the 3rd party application but as i said we know the consumer here. They way we are doing it is using oAuth2rize to create a token server routed to something like http://api.somewhere.com/token and posting to this location: POST https://api.somewhere.com/token grant_type=password& username=USERNAME& password=PASSWORD& client_id=CLIENT_ID The below is sample code, it may or may not be 100% correct or working but you should be able to find most of this stuff in the sample application on the oAuth2orize Github example application. We decided that our flow would be for this kind of exchange: 1 – Validate the client (using the ClientPasswordStrategy of passport.js) 2 – Setup a hook to catch the password exchange flow (Resource Owners Pasword Credentials) and do a simply validation of user credentials to validate that the user exists and that the credentials are correct 3 – Generate a token and store the details of the exchange in Redis (User, Client token etc) which we then use as our token store and place to cross reference tokens 4 – Subsequent requests are checked using the BearerTokenStrategy of passport.js to ensure the token is still valid. Hope that helps! Rob -- -- Job Board: http://jobs.nodejs.org/ Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines You received this message because you are subscribed to the Google Groups "nodejs" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/nodejs?hl=en?hl=en --- You received this message because you are subscribed to the Google Groups "nodejs" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
