I have implemented passport with GitHub-Strategy. Here's the Glith.
It works wonderfully and I'm receiving the user-profile on redirect from GitHub.
Now, I'm only trying to understand how this actually works 'under the hood'.
I did not find any similar question here on stackoverflow, neither on Passport.
So if I open Chrome Developer Tools during the Auth-Flow, the following seems to be going on when I click on Login with GitHub:
the node route /auth/github is called
node redirects to https://github.com/login/oauth/authorize?response_type=code&redirect_uri=https%3A%2F%2Frightful-exclusive-carriage.glitch.me%2Fauth%2Fgithub%2Fcallback&client_id=ccfcc73fac8223317176
the user is presented with GitHub-Login-Page
User types in GitHub-credentials and clicks 'Login'
GitHub checks the credentials
If valid credentials are provided, user is authenticated and GitHub redirects to the registered callback-endpoint, which is in my case: https://rightful-exclusive-carriage.glitch.me/auth/github/callback
The callback-url has a url-parameter, e.g. ?code=02337a951c242b9202fd. It's interesting to note, that it's a GET-method and nothing else is provided.
On the server, the passport.authenticate('github', ...) method is called inside of the /auth/github/callback-route.
When the GithubStrategy is instanciated, a callback-function is passed with the signature function(accessToken, refreshToken, profile, cb). Somehow magically, the accessToken and profile are fully available here. And I don't understand how this happens.
How is passport receiving the profile?
Is node.js making a server-side call to GitHub? Maybe with the ?code=<id> ?
Yeah that is exactly what NodeJS is doing. This doesn't have anything to do with Passport.JS or Node.JS. It is the OAuth mechanism of how authorizations work.
Whenever a the Identity provider like twitter/facebook calls your /callback with a ?code= query param It then hits another url and gets the AccessToken, RefreshToken and Idtoken(which is basically the user profile).
You can check out in the source code as well:
In this strategy.js#L157 and strategy.js#L173 of passports oauth strategy:
if (req.query && req.query.code) {
....
self._oauth2.getOAuthAccessToken(code, params,
function(err, accessToken, refreshToken, params) {
....
}
....
}
And the oauth2.js#L177 and oauth2.js#L190 of node-oauth package can see that:
exports.OAuth2.prototype.getOAuthAccessToken= function(code, params, callback) {
...
this._request("POST", this._getAccessTokenUrl(), post_headers, post_data, null, function(error, data, response) {
....
})
}
Bascially a POST request is being sent to the accessTokenUrl.
Related
I have a React app in Electron, and I'm trying to access the spotify API using the spotify-web-api-node library. However, I'm not sure exactly how the oauth flow is meant to work inside of an Electron app... Firstly, for the redirect URL, I used this question and added a registerFileProtocol call to my file. Then I added a specific ipcMain.on handler for receiving the spotify login call from a page, which I've confirmed works with console logs. However, when I get to actually calling the authorizeURL, nothing happens?
This is part of my main.js:
app.whenReady().then(() => {
...
protocol.registerFileProtocol(
"oauthdesktop",
(request, callback) => {
console.log("oauthdesktop stuff: ", request, callback);
//parse authorization code from request
},
(error) => {
if (error) console.error("Failed to register protocol");
}
);
});
ipcMain.on("spotify-login", (e, arg) => {
const credentials = {
clientId: arg.spotifyClientId,
clientSecret: arg.spotifySecret,
redirectUri: "oauthdesktop://test",
};
const spotifyApi = new SpotifyWebApi(credentials);
console.log("spapi: ", spotifyApi);
const authorizeURL = spotifyApi.createAuthorizeURL(
["user-read-recently-played", "playlist-modify-private"],
"waffles"
);
console.log("spurl: ", authorizeURL);
axios.get(authorizeURL);
}
I'd expect the typical spotify login page popup to show up, but that doesn't happen. I'd also expect (possibly) the registerFileProtocol callback to log something, but it doesn't. What am I meant to be doing here? The authorization guide specifically mentions doing a GET request on the auth url, which is what I'm doing here...
In a desktop app it is recommended to open the system browser, and the Spotify login page will render there, as part of creating a promise. The opener library can be used to invoke the browser.
When the user has finished logging in, the technique is to receive the response via a Private URI Scheme / File Protocol, then to resolve the promise, get an authorization code, then swap it for tokens. It is tricky though.
RESOURCES OF MINE
I have some blog posts on this, which you may be able to borrow some ideas from, and a couple of code samples you can run on your PC:
Initial Desktop Sample
Final Desktop Sample
The second of these is a React app and uses a Private URI scheme, so is fairly similar to yours. I use the AppAuth-JS library and not Spotify though.
I'm working on an Ionic application.
On the one hand I have an auth basic form in which people fill in their username and password. On the other hand I'd like to implement authentification with JSON Web Tokens and Node JS.
The workflow would be this one : as soon as a user fills in his credentials, they will be sent with a POST request. If these credentials are correct, the user can access to the application and gets an access token as a response.
The thing is that I'm a little bit lost with all that concepts. I built a form and sent informations with a POST request. I managed to create some APIs with Node JS and that's ok. I see how to build a authentified webservice too (e.g : https://github.com/jkasun/stack-abuse-express-jwt/blob/master/auth.js).
But I concretely don't understand the links between the html form and the authorisation check part..
To be clearer, how is it possible to make the html part and the Node JS scripts communicate together ?
Before posting that question I made many researches and found many stuff on building an authentified API. But there was very few advice on how to make it communicate with the client part (I mean the form), which is what I have to do.
If anyone has any ressources (document, Github examples..) on that, I'll greatly appreciate. But I would be very happy too if someone try to make me understand these concepts. I guess I have to improve my knowledge on all that so that I could test some POCs.
Many thanks in advance !
JWT General flow:
1- Authenticate using a strategy (You done it)
2- Deliver an accessToken along with response (You done it)
3- The client MUST store this accessToken (LocalStorage is the best place, not cookies: They are vulnerable to csrf attacks)
4- On every request you are going to make to a protected area (where user is supposed to be authenticated and authorized), make sure to send you accessToken along with it, you can put it on Authorization header, a custom header, directly in body of the request... Basicaly just make sure to send it properly.
5- On the server receiving client requests, you NEED to verify that token (You verify it by checking the signature of the accessToken).
6- If he is authorized, great, if not, send back an HTTP Unauthorized Error.
Here is my implementation using an accessToken on a header + passportjs-jwt:
Client code
To store token:
localStorage.setItem('accessToken', myAccessToken);
To send it:
const myAccessToken = localStorage.getItem('accessToken');
{
headers: {'Authorization', `Bearer ${myAccessToken}`}
}
Server code
1- Configure passport
passport.use('jwt', new JwtStrategy({
jwtFromRequest: jwtPassport.ExtractJwt.fromAuthHeaderAsBearerToken(),
secretOrKey: myAccessTokenSecret,
passReqToCallback: true
}, (req, payload, done: (err?, user?) => void): void {
User
.findOne({where: {id: req.params.id}})
.then((user: User) => {
if (!user) {
return done(new Error(`No user found with id: ${req.params.id}`), null);
}
return done(null, user);
})
.catch((e: Error) => done(e, null));
}));
Pay attention to callback: If your callback is called, it means that passport has successfuly verified the token (It is valid). In my example, i get the user details in database and this is the user that will be returned and put in req.user object passed to my controller below:
2- Finally, the controller route (protected area):
.get('/users/:id', passport.authenticate('jwt'), (req, res, next) => {
// do stuff in protected area.
}
And that's it. If you want more security, check refreshTokens implementation.
I used passport because i found it relevant in my case, but you can write your own handler, by using jsonwebtoken and just calling its "verify" function.
You can find documentation of passport jwt strategy here => http://www.passportjs.org/packages/passport-jwt/
I am using multiple passport stratergy across my app.
Now, since I am using multiple passport strategy to connect (and not to just sign-in), I decided to Google things on how to do it.
This is where I stumbled upon this code
passport.authenticate('meetup', (err, user, info) => {
if (err) { return next(err); }
if (!user) { return res.redirect(process.env.CLIENT_ADDRESS); }
req.logIn(user, function(err) {
if (err) { return next(err); }
return res.redirect(process.env.CLIENT_ADDRESS);
});
Here I am unable to comprehend what is happening, like for first question, what is if (!user), Does it mean req.user
Second, there is req.logIn()
According to passport docs,
Passport exposes a login() function on req (also aliased as logIn())
that can be used to establish a login session.
and
When the login operation completes, user will be assigned to req.user.
Then what is the difference between using serializer/deserializer when compared with req.login?
Also in the callback, we can always do this
passReqToCallback: true
}, (req, accessToken, refreshToken, params, profile, cb) => {
to get req
To summarize can someone please help me comprehend the above code snippet?
At a high level Passport.js is a middleware that "serializes" a user identity in a request/response header (usually a session cookie). This serializing step means that it's taking the login information that identifies a user and produces a new object that represents the user. Think of this object as a key 🔑 card that only Passport will know how to interpret.
When a user makes additional API requests they pass that same identification header back. Passport auths the request by "deserializing" it to identify what user is making that request.
req.login() is the magic that is generating a session for a user. This session represents how long a login is good for without having to re-authenticate.
Let's take a look at the beginning of your snippet:
passport.authenticate('meetup', (err, user, info) => {
...
if (!user) { return...
In this snippet, passport is being set up as middleware. When a request comes through, passport behind the scenes has already interpreted the request header by deserializing the cookie and determines if it represents a user. If there is not a user or the request header does not represent a user, the request is not authorized.
req.login aliased as req.logIn
Passport exposes a login() function on req (also aliased as logIn()) that can be used to establish a login
session.
When the login operation completes, user will be assigned to req.user
Note: passport.authenticate() middleware invokes req.login() automatically.
Use a lower version of passport for this feature v0.4.1
You can install this with
npm install passport#^0.4.1
Your req.login function should work with that version.
I have been attempting to use the passport-oauth2 module to use the Log In With Paypal service. At this point, I'm only working with the sandbox and not production (yet).
I am successfully using the passport-google-oauth and passport-amazon to authenticate with each of those services via oauth2. Given this, I'm confused about what I'm doing wrong with PayPal.
With PayPal, I can't get the sandbox to work at all. I get a login screen that takes credentials, but after entering them I am getting a connection reset error every time. I have tried logging out of all PayPal sessions, closing browsers, etc. Despite my client-side fiddling, I never make it back from PayPal to my callback.
So...to the code!
I have a configuration object for development:
"paypal" : {
"clientID": "copied from the developer My REST Apps test credentials",
"clientSecret" : "more copied test credentials",
"callbackURL" : "https://localhost/auth/paypal/cb",
"authorizationURL": "https://www.sandbox.paypal.com/webapps/auth/protocol/openidconnect/v1/authorize",
"tokenURL": "https://api.sandbox.paypal.com/v1/identity/openidconnect/tokenservice"
}
And I have a little library that does this:
var PayPalStrategy = require('paypal-oauth2').Strategy;
exports.paypalStrategy = function (conf) {
// 'conf' is the configuration from the first code block
return new PaypalStrategy({
clientID: conf.clientID,
clientSecret: conf.clientSecret,
callbackURL: conf.callbackURL,
authorizationURL : conf.authorizationURL,
tokenURL: conf.tokenURL
},
function (accessToken, refreshToken, profile, done) {
// we never get here because our connection is reset.
});
};
And my routes are simple:
app.get('/auth/paypal',
passport.authenticate('oauth2', {scope: 'profile'}),
function (req, res) {}
);
app.get('/auth/paypal/cb',
passport.authenticate('oauth2', { failureRedirect: '/login' }),
function (req, res) {
res.redirect('/profile');
});
My guess is that I'm (a) getting something wrong with the endpoints or (b) I'm missing some step with the test account configuration on PayPal's dev site. Sadly, I can't seem to find what I need in the docs. Any help or guidance is appreciated.
Mine worked with the following:
1) Clear browser cache and history.
2) Delete cookies.
And try again.
After a few hours I mucking around with passport, I ended up moving towards using the node-palpal-sdk instead. I think what makes it confusing is how paypals oauth flows talk about openid on the endpoints urls. Here's a gist of how I got it working, straight forward after you put the pieces together:
https://gist.github.com/jkresner/8a581e50dcac58edbd10
I was looking for a way to let my client authorize with the facebook JS SDK and then somehow transfer this authorization to my node server (so it can verify requests with the fb graph api)
I stumbled across:
https://github.com/jaredhanson/passport-facebook/issues/26
&
https://github.com/drudge/passport-facebook-token
what seems to be an entirely different strategy from passport-facebook.
Am I correct when assuming that:
One logs in with the fb JS SDK, and then the facebook-token strategy somehow extracts the token and fb id from the document or body object?
Or is there any other decent way to achieve this? I'm namely trying to avoid the redirects enforced by the server SDKs
I've spent a couple of days this week trying to figure out the best way to use Facebook Authentication for a private API, using passport.js — passport-facebook-token is perfect for this.
You are correct in assuming these are two separate authentication strategies. You don't need passport-facebook installed to use passport-facebook-token.
If you have Facebook authentication implemented in the client-side JS (or iOS etc.), and are looking for a way to then authenticate API requests using your user's Facebook authToken, passport-facebook-token is a really elegant solution.
passport-facebook-token works totally independently of passport-facebook, and basically handles the redirects required by Facebook internally, before passing the request along to your controller.
So to authenticate an API route using passport-facebook-token, you'll need to set up a passport strategy like so:
passport.use('facebook-token', new FacebookTokenStrategy({
clientID : "123-your-app-id",
clientSecret : "ssshhhhhhhhh"
},
function(accessToken, refreshToken, profile, done) {
// console.log(profile);
var user = {
'email': profile.emails[0].value,
'name' : profile.name.givenName + ' ' + profile.name.familyName,
'id' : profile.id,
'token': accessToken
}
// You can perform any necessary actions with your user at this point,
// e.g. internal verification against a users table,
// creating new user entries, etc.
return done(null, user); // the user object we just made gets passed to the route's controller as `req.user`
}
));
It's worth noting that the User.findOrCreate method used in the passport-facebook-token Readme is not a default mongo/mongoose method, but a plugin that you'll have to install if you want it.
To use this auth strategy as middleware for any of your routes you'll need to pass it an access_token object either as a URL parameter, or as a property of the request body.
app.get('/my/api/:access_token/endpoint',
passport.authenticate(['facebook-token','other-strategies']),
function (req, res) {
if (req.user){
//you're authenticated! return sensitive secret information here.
res.send(200, {'secrets':['array','of','top','secret','information']});
} else {
// not authenticated. go away.
res.send(401)
}
}
NB. the access_token property is case-sensitive and uses an underscore.
The documentation for passport-facebook-token isn't extensive, but the source is really well commented and pretty easy to read, so I'd encourage you to take a look under the hood there. It certainly helped me wrap my head around some of the more general ways that passport works.