I'm working on a SPA which uses Facebook client side authentication. After successful login, for each API request I want to use the accessToken on the server side to verify the user. I use Koa.js.
What would be a good way of doing it? I'd be happy to use a middleware for this job if there is any.
Related
I'm trying to learn how to utilize auth0 to handle user authentication for an api I am currently creating.
My api has two endpoints:
Login endpoint: /api/login
Request access token endpoint: /api/auth?code={code}
Here the authentication flow is:
User goes to the login endpoint of my api.
User is redirected to auth0 ui.
User inputs their login credentials.
Auth0 redirects back to /api/auth where a request for an access_token is made using the login code.
Firstly, is my understanding the Oauth authentication flow correct? If so, how best should my api handle the initial login redirect to auth0?
Because at the moment when I hit up /api/login from the front-end ui it just returns the html of the login page at auth0. Should I instead return a 302 with the redirect url or is it possible to create an endpoint where the user inputs the username & password via my api and avoids the redirect?
---update---
After a user has authenticated via auth0 they receive a access_token and id_token which should my api use to verify the user is who they say they are?
Not sure if my understanding is correct but I belive that my frontend ui is the OAuth client application and my API service is an OAuth resource server. As such does my api need to call out to auth0 /userinfo to verify the user?
Assuming you are trying to protect an end-user application (your question wasn't clear on that), my understanding is if you are using Auth0, you likely won't need an /api/login and api/auth API. If you are using Auth0 you can get those things during your authentication via Auth0.
I would say your APPLICATION (not API) would redirect the user to the Auth0 login endpoint. You would do that by incorporating the Auth0 SDK of choice, depending on what you're building. For example, if you're building a web app, you may choose to incorporate auth0.js and call webAuth.authorize() to trigger the login. During that login, if you have configured an API within Auth0, and you provide the proper Scope and Audience during your login, your response will return an API token.
Then your user is in a state on the client side where you are logged in, and you have a token. You can then provide that token to your API, and your API can validate that token as needed. Auth0 also has various libraries for token validation (like this spring security one, for example).
Lastly, the question on which oAuth flow to use, that also depends on what type of app you're protecting. There are again Auth0 docs to help. The flow depends on if you're building a server-side web app, a SPA, a native app, etc. Your question was a little confusing, and it sounded a bit like you are building an API and want to protect that. If there is no client-side app (only machine-to-machine API calls), then you wouldn't be dealing with HTML and login pages. You'd likely be getting into the Client Credentials flow, which last I checked was only included for Enterprise Auth0 users.
I am building a SPA (Single-page application) that is going to consume and REST API. My application will use the facebook login.
Just to clarify my ideas:
I will use Facebook SDK (javascript) to authenticate my new user. Facebook will give me an access token. This will run on client side.
Now, i will make a request to my REST API. Do i need to pass the access token to the REST API? DO i need to verify always to see if the user is logged?
I know it is a newbie question..
As long as you are using the JavaScript SDK (and FB.login), you don´t need to worry about the Access Token - at least not in most cases.
You can verify if a user is authorized already by using FB.getLoginStatus on page load.
I have the following use case
My application on iOS is using the FaceBook iOS SDK to authenticate with FB
The application then make a REST call over https to my server to register the FB account to their service account (the service I am offering)
In step 2 the client is sending the FaceBook UID.
My problem is that the server has no FB integration so has to reply on the client sending the right FaceBook UID.
So the problem is obvious, a hacker can attach someone else FaceBook account to their service account .
What I would like is for the server (Java) to be able to validate that the user who is sending the request owns the Facebook UID in question.
I have been searching online and cannot find anything that I think will work.
I came across a vague post about using the FB signedRequest field, this could be passed to the server to validate the user.
Any idea would be appreciated.
Here is a thought:
Once you authenticate the user in your iOS app, get the access_token, and pass only this in your REST call to your server.
On the server side, make a request to https://graph.facebook.com/me?access_token=... using the access_token that you transmitted. If the access token is valid, you will get all the the user's data proving that you have a valid, authenticated user.
If you wanted to be extra sure, you can also request http://graph.facebook.com/app?access_token=... to be sure that the access token was created by your app.
We have a website where the only way to login and authenticate yourself with the site is with Facebook (this was not my choice). The first time you login with Facebook, an account gets automatically created for you.
We now want to create an iPhone application for our site and also a public API for others to use our service.
This question is about how to authenticate with our website from the app/API and is broken into 2 parts:
What is the correct way to handle REST authentication from an API to a website which only uses Facebook OAuth as an authentication method?
I have read and researched a lot about standard methods of authentication for REST API. We can't use such methods as Basic Auth over HTTPS, as there are no credentials for a user as such. Something like this seems to be only for authenticating applications using the API.
Currently, the best way I can think is you hit an /authorize end-point on our API, it redirects to Facebook OAuth, then redirects back to the site and provides a 'token' which the user of the API can use to authenticate subsequent requests.
For an official application that we create, we wouldn't necessarily need to use the public API in the same way. What would be the best way then to talk to our website and authenticate users?
I understand (I think) how to authenticate 3rd-party applications that are using our API, using API (public) keys and secret (private) keys. However, when it comes to authenticating the user who is using the app, I am getting rather confused about how to go about it when the only way we have to authenticate a user is Facebook.
I feel like I'm missing something very obvious, or don't fully understand how public REST APIs should work, so any advice and help would be greatly appreciated.
UPDATE: see below
I've been thinking hard about this question too. It's not entirely clear to me yet but here's the route I am thinking of going. I am creating a REST API an my users only auth with Facebook connect.
On the CLIENT:
Use the Facebook API to login and get an OAUTH2 code.
Exchange this code for an access token.
In every call to my custom API I'll include the Facebook user id and the access token.
On the API (for every method that requires user authentication):
Make a request to the /me Facebook graph using the access token from above.
Verify that the Facebook user id returned matches the user id passed to my API from above.
If the access token has expired additional communication is required.
I have yet to test this. How does it sound?
--- Update: July 27th, 2014 to answer question ---
I only use the above exchange once upon login. Once I determine which user is logging in, I create my own access token, and that token is used from that point going forward. So the new flow looks like this...
On the CLIENT:
Use the Facebook API to login and get an OAUTH2 code.
Exchange this code for an access token.
Request an access token from my API, including the Facebook token as a parameter
On the API
Receive access token request.
Make a request to the /me Facebook graph using the facebook access token
Verify that the Facebook user exists and match to a user in my database
Create my own access token, save it and return it to the client to be used from this point forward
This is my implementation using JWTs (JSON Web Tokens), basically similar to Chris' updated answer. I have used Facebook JS SDK and JWT.
Here's my implementation.
Client: Use Facebook JS SDK to log in and get the access token.
Client: Request JWT from my API by calling /verify-access-token endpoint.
MyAPI: Receives access token, verify it by calling /me endpoint of Facebook API.
MyAPI: If access token is valid, finds the user from database, logs in the user if exist. Create a JWT with required fields as payload, set an expiry, sign with the secret key and send back to the client.
Client: Stores the JWT in local storage.
Client: Sends the token (the JWT from step 5) along with the request for the next API call.
MyAPI: validate the token with the secret key, if token is valid, exchange the token for a new one, send it back to the client along with the API response. (No external API calls for verification of the token here after) [if the token is invalid/expired request client to authenticate again and repeat from 1]
Client Replaces the stored token with the new one and use it for the next API call. Once the token expiry is met, the token expires revoking access to API.
Every token is used once.
Read more answers about security and JWT
How secure is JWT
If you can decode JWT how are they secure?
JSON Web Tokens (JWT) as user identification and authentication tokens
I am trying to answer the same question and have been going through a lot of reading recently...
I won't have "the" answer but things are getting a little clearer for me. Have you read the comments in the article you mentioned? I found them really interesting and helpful.
As a result, and in the light of how things have evolved since the first article has been written, here's what I think I'll do:
HTTPS everywhere — this allows you to forget about HMAC, signing, nonce, ...
Use OAuth2:
When authentication requests come from my own apps/website, use this 'trick' (or a variation of it) described in a reply to the article mentioned before.
In my case, I have two types of users: those with classic login/password credentials and those who have signed up with Facebook Connect.
So I'd provide a regular login form with a "Login with Facebook" button. If the user logs in with his "classic" credentials, I'd just send these to my OAuth2 endpoint with a grant_type=password.
If he chooses to log in via Facebook, I think that would be a two-steps process:
First, use Facebook iOS SDK to open an FBSession
When that's done and the app is given back control, there should be a way to get a Facebook ID for that user. I'd send this ID alone to my OAuth2 endpoint with an extension grant understood by my server as "using an FB User ID".
Please note that I am still heavily researching on all this stuff, so that might not be a perfect answer... maybe not even a correct one! But I think that would make for a good starting point.
The idea of using an "extension grant" for the Facebook authentication might involve having to register it to do things properly? I'm not quite sure.
Anyway, I hope I was able to help you even a bit, and that at least it can start a discussion to find the best solution to this problem :)
Update
The Facebook login is not a solution as pointed in the comments: anybody could send an arbitrary user ID and log in as this user on the API.
What about doing it like this:
Show a login form with a "Facebook login" button
If this login method is chosen, act kinda like the Facebook SDK: open a web page from your authentication server, which will initiate the Facebook login.
Once the user has logged in, Facebook will use your redirect URL to confirm; make that URL point to another endpoint of your authentication server (possibly with an extra parameter indicating the call came from an app?)
When the authentication endpoint is hit, the authentication can securely identify the user, retain its FB User ID/FB Session and return an access token to your app using a custom URL scheme, just like the Facebook SDK would do
Looks better?
I receive an access token when a client allows my application on his facebook account. Based on that access token and an url I can print all his friends. I have a question: does this access token appears all the time the user logs in his application? i am asking this because the second time the user logs in in my application where i have a web browser the friend list doesn't pop up because the response from the site does not contain an access token anymore. where am i wrong? how can i check after the user accepts my app that he is online or loged in - if i want to prints his friends.
First thing: sounds like you want to add the scope offline_access because what you are trying to do is really leveraging the FB authentication mechanism.
Also: It is probably easiest to use the FB Connect button and the JavaScript Client API, unless you intend on using the graph or REST API from a back-end server.
If you ARE intending to use back-end API integration read this paragraph:
I have found it helps to ensure that you are using a proper authenticate URL (I use www.facebook.com/dialog/oauth but others have worked in the past..). Just don't use an authorize only URL, or users will be forced to grant permissions repeatedly (never really understood that 'feature'). Next redirect the user to the URL with a request token, and keep your request secret on the server side (or well encrypted if on the client side). After login, you receive the callback with an OAuth Verifier. Access verification URL graph.facebook.com/oauth/access_token with the Verifier and you will receive the OAuth Access Token. Save that token, as well as the user id.
As for checking that the current user is logged in, and/or has authorized your app and/or has friends using your app:
Have a look at FB Connect API:
http://developers.facebook.com/docs/guides/web/#login
call FB.init first, and then when you call FB.getLoginStatus, you will get an OAuth Token if the current user is logged in to FB and has previously authorized your app (either via the Connect Button or OAuth flow):
$wnd.FB.getLoginStatus(function(response) {
if (response.session)
var authToken = encodeURIComponent(response.session.access_token);
});
When executed in conjunction with the authenticate flow mentioned, users that have already authorized your application will get the same OAuth Access Token returned from previous calls, that you can use with the JS Client, Graph, or REST APIs.