I'm using FirebaseUI to authenticate users on my website. I have a need for checking if the user is logged in on the server side (in PHP code). How can I accomplish this?
I believe I've seen something about something called JWT, but I don't really understand what I need to do in order to make this work.
You need to get the Firebase ID token by calling currentUser.getIdToken() on the client. You can then send this ID token to your server and verify it before parsing its content and get the user's uid from it. Refer to this documentation for verifying ID tokens: https://firebase.google.com/docs/auth/admin/verify-id-tokens#verify_id_tokens_using_a_third-party_jwt_library
Related
I'm trying to set up Google OAuth2.0 from this guide and I have everything set up and running. I can get the authorization code, the access_token, and the refresh_token to show up in my console.log's. My question is which one of these tokens can I use to properly identify and log in a user to my backend?
In a normal scenario, a user would enter a username & password and that would uniquely identify them. However in the Google OAuth2.0 case, it seems the authorization code, the access_token, and the refresh_token all cannot be used to properly identify and log someone in. Is this understanding correct?
I read a similar post but it doesn't seem to provide a very recent answer that also securely identifies the logged in user.
If I cannot use any of the above mentioned tokens to securely identify and log in a user, is it even possible? How come I see other websites and apps use "sign in with Google" and "sign in with Facebook"?
Another solution I read in a different StackOverflow post said to just get the account ID and use that as an identifier. Isn't that insecure? Can't someone guess the account ID? Also this would be assuming these account IDs are private.
My question is which one of these tokens can I use to properly identify and log in a user to my backend?
the id token from open id connect.
explanation
You are confusing authorization and authentication.
Oauth2 a user to grant and authorize your application access to their data the access token gives you access to their data for a limited time (1 hour). If the user is off line you can use the refresh token to request a new access token. None of theses will tell you that a user is behind the calls.
open id connect allows you to authenticate a user logging in will return an id token
Id token verification
After you receive the ID token by HTTPS POST, you must verify the integrity of the token. Verify the integrity of the ID token
I have implemented authentication mechanism on some mobile application using JWTBundle with symfony 3. Until now the process requires users to submit both their email and password in order to authenticate. This works great.
Today I would like to grant access/create_account using Facebook authentication.
From the mobile app, users will access the application without submitting any password but instead FB will probably return user's Facebook identifier along with some other info. I will then post those datas to login_check route.
At this point I need a way to check (at the very beginning of request processing flow) whether login_check POST datas are standard username/pwd credentials (which I guess are handled through daoauthenticationprovider by default ? which in turn pass the processing to JWT in order to create a authentication token) and if not, fallback to another custom XXAuthenticationProvider to handle those datas (eg. if a facebook identifier is present then lookup the user account with FB API, do stuff … then create a JWT token).
I read couples of articles dealing with Symfony's Security components but none explained the whole thing clearly neither exposed a way to proceed. I still have difficulties to figure out how I could hook into the security firewall to achieve this.
Is this a way to go and how can I achieve this ?
Thank you.
I am trying to implement a login for my mobile app to my backend. I previously used to use a method that required hashing on mobile site and backend site. The password would be hashed saved on the mobile site and be included in the hash. If hashes on mobile side and backend side would be equal, the request would be valid.
However I wanted to add Facebook login to my login system so I kinda find out it was not gonna work the way I had built it before. I came to the conclusion that I probably have to change the entire method to token login.
What I have currently functioning is Facebook button on mobile side, this creates for me a Facebook userid and Facebook access token. I send both these values to my backend and use a Facebook graph call to retrieve the facebookid from the access token. if both the Facebook userids are equal. I either register the user or log him in.
This is where I get stuck. I now want to generate my own token to send back to the mobile side, because I have custom login (email+password) (Facebook is just an option). So I think using my own auth token for both ways is the best.
I have a few questions about this token:
What should the token exist of?
Do I need to save this token on the mobile (not hashed?)
What is the best way to built in expiring time and automatic refresh token
What I can't really understand is the security of this authentication method. Sending a token over a request that gives you access to user information is just as bad as a plain password I think? Is SSL connection simply enough?
I understand these are a lot of question in one but I hope someone can give me a clear explanation.
Thank you
You can try JWT (JSON web token), it's really simple. The idea its, when you do the login, the servers return you the JWT and you simply have to save it in your mobile app. Then you have to pass it as a header (assuming you are developing for Android):
request = new HttpGet();
request.addHeader("Authorization", "Bearer " + Global.loginData.jwt);
Say the page where user can update his own profile: profile_update.php?id=1234567...(user's Google id).
Question:
How can I restrict access with the returned authResult or me? (I mean which item in the object will help that, not how to get these item out).
or Do I still need to build a server side $_SESSION for that?
You could do some validation on the client side using the auth result, but you'd also want to verify that the request you get on the server side is from who you think it is from to prevent cross-site request forgery attacks. So you'd need something that validate that the POST that update the profile came from an authenticated user, not just that the POST data was in the correct format. So typically, your form will send a specific code (a CSRF token) and that same token must be present in the user's cookies (or a server side session token, which in PHP can be accessed via $_SESSION).
The Google+ Sign-In button bears a striking similarity to the Facebook Login API, and I like that.
The Facebook JS SDK has a signed_request parameter that's provided on the client side but which can be passed to my server, verifying that client-side authentication has taken place. It's cryptographically signed by Facebook, which allows me to verify that the client is logged in without talking to the Facebook on the server side.
Is there a way to do something similar with the G+ JS API? Specifically, I want to do client-side authentication, then POST some data to my server and verify that the client really is logged in to Google, without initiating a server-side request to Google.
(I want this because I only want to use the sign in button as a registration mechanism; I don't want to post to Google Plus or get the user's list of friends or anything like that, which would normally require a full access token.)
Google+ does not make requests to your application on the user's behalf at this time, outside of a callback URL set as part of a vanilla OAuth 2.0 flow.
When receiving a new token or authorization code, you should make the tokeninfo request server-side in order to verify that the token you've received is legitimate, and for the intended user.
I'm not sure which platform your server is using, so I can't paste the relevant code, but please see here for a code sample.
So, actually there is a pretty good match for that parameter, the id_token that is returned along with the access_token. It's a signed json web token that includes a userid, the client ID and so on. It sounds like this would address your use case! Take a look at http://android-developers.blogspot.nl/2013/01/verifying-back-end-calls-from-android.html this blog post by Tim Bray - it's Android focused, but the same logic pretty much works for any client.
Once you get this, you know its valid at the point of delivery, just liked a signed_request. Of course in either case if the user signs out or revokes access to your app the access token may no longer be valid for making calls.