Cannot do Access Control with third-party login about loopback-component-passport HOT 16 CLOSED

In reading through lib/passport-configurator.json there is a block that reads:
Line 464

 if (info && info.accessToken) {
              if (!!options.json) {
                return res.json({
                  'access_token': info.accessToken.id,
                  userId: user.id,
                });
              } 

Basically what this says is that by setting a 'json' option for your authentication provider in your providers.json file that it'll return a json response with the access_token and user id instead of setting a cookie.

My provider file looks like this:

{
 "auth0": {
   "provider": "auth0",
   "module": "passport-auth0",
   "clientID": "xxx",
   "clientSecret": "xxx",
   "domain": "xx",
   "callbackURL": "/auth/auth0/callback",
   "successRedirect": "/api/users/me",
   "authPath": "/auth/auth0",
   "json": true
 }
}

Success Redirect is no-longer honored, but in my case, that's OK since this response that is returned is exactly what I need and seems like what others in this thread are looking for.

This is the response from the callback:

{
"access_token":"jIJwBgeSURfMT9A41uzU3PvLDcNNjTnRpbyDSjHydH0bfkT8iRo1pFXKuDDZNg2a,
"userId":1
}

from loopback-component-passport.

This is not the case. Let me explain the auth workflow we use, which may help you understand how to work with 3rd party auth:

1. User's browser initiates auth, is redirected to auth provider, and then is returned to the success callback URL.
2. API code receives evidence of auth and find or creates the user in the database.
3. API code creates an AuthToken for this new user session.
4. AuthToken is returned to client that initiated the auth request.
5. AuthToken is stored in memory or local storage to facilitate future calls to the API.

As you see, you are still working with auth tokens. The token is created after Passport succeeds and then used for future requests.

from loopback-component-passport.

@zschmid thanks ever so much for posting that.

I came here because what I am using LoopBack to build a backend for a native Android application, which is to offer the user the choice of logging in with Google. I was able to get as far as obtaining an OAuth2 auth code (by using the Google Sign-in Android library), which I could then use to pass to my LoopBack API's /auth/google/callback?token=xxx endpoint to successfully log in. But, the response of course by default sets cookies, rather than giving me a LoopBack access_token of the type that I'd normally get when logging into LoopBack natively (or 'locally' if that's the right terminology).

What I could not get my ahead around was whether the normal way of doing things in this situation would be for me to programmatically extract the access_token from the set-cookie response header, or if it's the norm (in the case of what I'm doing) that the REST API should just provide an access_token in the actual response (which is what I now have thanks to the above), or even if the normal way of doing things is to use an Android HTTP/REST library that actually supports cookies as if it were a browser.

It looks like I have a solution now which I'm very thankful for, but if anyone happens to have comments on what I've said in terms of what is the usual workflow for an Android/iOS application OAuth2 login (from the point of having the auth code from Google), I'd be grateful.

If it is the case that using "json":true to get a native access_token in the response is exactly how it should be done with mobile applications then I might propose I raise a PR to make this explicit in the documentation.

from loopback-component-passport.

I have the same issue. For now this plugin is completely useless : / . I don't need a link or something similar. People should be able to login via passport and access restricted user content after logging in.

from loopback-component-passport.

@doublemarked Thank you for the explanation. That's the exactly the workflow supported by this component.

from loopback-component-passport.

Indeed, that was super helpful and saved my day.

For more details, the documentation for this component is pretty thorough:

http://docs.strongloop.com/pages/releaseview.action?pageId=3836277#Third-partylogin(Passport)-Loginandaccountlinking

from loopback-component-passport.

@raymondfeng Is there anything to fix here? I'm reassigning to you to complete the triage as you're already commenting on this issue.

from loopback-component-passport.

If possible, could someone clarify a few of the steps outline in @doublemarked great response above? Steps 1 and 2 are clear and I am able to redirect to Facebook as an auth provider and use successRedirect to get my user at /api/Users/{id}, but I am unsure of how to obtain an AuthToken from here to allow my client to make subsequent authenticated request to the REST API after this? Any clarification or examples would be greatly appreciated.

from loopback-component-passport.

@sharkinsspatial I believe the loopback-component-passport will set a cookie that contains the accessToken. Or, you can set up a server-side template that somehow or another gets the access token back to the client.

For example, in our code we launch the auth process in a small popup window. Once Passport completes, in the popup ls rendered a template with the accessToken and the popup window transmits it back to the SPA.

However, our circumstances are more complex because of CORS. The cookie is more straight forward and easier for most situations.

I'll add - if you're using Angular, I believe the LB-generated angular service will automatically read this cookie.

from loopback-component-passport.

"if you're using Angular, I believe the LB-generated angular service will automatically read this cookie."

If that's true, I would be interested to see how it's done.

My attempts (trying to integrate facebook login specifically) did not work OOTB.

There is a big discussion (with extra links) here: strongloop/loopback-sdk-angular#74

This helped me solve my issues.

Two side notes:

a) I think this will only work (without modification) when your angular site is on the same host as your loopback API cause I believe the cookie is set at the host level....So a site www.example.com trying to auth against an LB installation at api.example.com would fail unless the cookie in component-passport is set for example.com.

b) Specifically for facebook, if you're using the javascript SDK to login, passport-facebook-token works with loopback-component-passport as well. Just npm install it and add a provider for it.
Then you can just GET/POST your fb token to the callback endpoint defined in providers.json (ignore the auth url) and get an LB access token back. I came across this while implementing facebook auth for loopback on an android client

from loopback-component-passport.

I may be mistaken about the Angular service using the cookie - we are not using the cookie.

a) I think this will only work (without modification) when your angular site is on the same host as your loopback API cause I believe the cookie is set at the host level.

Yes, this is absolutely the case, and why I mentioned that under CORS you need something more complex.

from loopback-component-passport.

@doublemarked, I am in a similar situation where I have an SPA on one domain making requests to a Loopback REST API on another domain. When doing this previously with hand rolled solutions I have done my third party passport authentication and then appended the access token as a query parameter in the redirect to the SPA where I can store it locally. In this case I was hoping for something similar where I could use the access token in the redirect, but there doesn't seem to be a canonical method for doing this.

from loopback-component-passport.

In theory you should be able to provide a customCallback in the options so that loopback adds the access token and user id to your success redirect (which would solve the issue of the cookies not being available due to diff domains).

Someone else had a similar issue but at the time couldnt get it to work. See here:

#14

from loopback-component-passport.

Thanks @clockworkgr, that seems to be exactly what I was looking for. I'll give this a try and see how it works out.

from loopback-component-passport.

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

from loopback-component-passport.

This issue has been closed due to continued inactivity. Thank you for your understanding. If you believe this to be in error, please contact one of the code owners, listed in the CODEOWNERS file at the top-level of this repository.

from loopback-component-passport.