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);
Related
I am trying to integrate the Google sign in sdk into my site.
I have already added the GSI button to my site and on clicking it, google sends the IDtoken containing the user info to my oauth endpoint.
Using this token, I can now create a new user account.
So far so good.But I am not sure what I am to do from here.
Should I put this IDtoken into a http_only and secure, cookie so that all authz server requests will contain the userid?
I am seeing lots of cookie and local storage based data has been been added to my sites jar. Am I supposed to use them in any way?
What do I need to do after the token expires after 1 hr? Do I need to have my users login yet again? I did not get any refresh token along with the idtoken. Do I even need to handle the refresh token or is the gsi sdk supposed to take care of all that for me?
Another part which is not clear is what do I get from using the Google sign in button/sdk vs the general Oauth-openid flow.
We have an Instagram client id and client secret, and already have gone through the documentation of generating access tokens which requires redirect url.
Note that we also have disabled the implicit OAuth flow.
Now we already have generated the access token using URL below (for authenticated user, it returns the access token appended in the response URL)
https://api.instagram.com/oauth/authorize/?client_id={client_Id}&redirect_uri={redirect_url}&response_type=token&scope=public_content
Can this token be stored in the database / configuration files and re-used for any new Instagram API requests? e.g.
https://api.instagram.com/v1/users/{user_id}/media/recent/?access_token={reusable_access_token}
Based on the official documentation, we understand that the access token can become invalid at any point of time, we would like to know if there are any specific scenarios which leads to invalidation of the access token?
What would be the best way to generate token once and use it for each API request? We definitely do not want users to enter credentials manually to generate tokens.
Unfortunately at that point it's not possible:/ Instagram doesn't provide refreshing access token in the background.
User needs to login with their credentials, so you can obtain new access token. Some kind of workaround (not nice, but it's working) is to watch for error type OAuthAccessTokenException and notify the user via e-mail about such fact. He will have to login once more, so you can get fresh and working access token.
Also, please keep in mind that access tokens has a pretty long life span. It doesn't expire after a day or two, unless Instagram API has some issues (like just now OAuth - unable to exchange code to access token for some users).
Otherwise it works really well.
However it would be super nice if Instagram could add to their API renewal option in the background for access tokens for users that autorised your app, but their token expired:)
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 have a mobile app which will call a REST API written using Laravel(5.2) framework.
This article on Laravel API authentication mentions how to authenticate users making calls to such an API. The caller should send the correct api_token to the server in the request.
My question is what would be a good way to get the api token to the mobile app? I'm currently thinking of creating a rest api which will authenticate the user based on username and password sent in the request and send the api_token in the response if the user sends a valid username/password pair. Is this method correct/secure? What things should I consider additionally if I do use this method?
You must use one of this methods to have a secure API
JWT TOKEN https://github.com/tymondesigns/jwt-auth
OAUTH2 https://github.com/lucadegasperi/oauth2-server-laravel
With this methods you only send once username and password and you obtain a token that is valid for a time you can decide. But as bigger is the time, more insecure.
To solve this, there are a renew token methods. With a valid token, you can obtain another valid and refresh the old. In this way, the username and password are more protected because they are not sent in every request.
Is not a good idea have the same token for each user all the time, as you saw in the example you provide. It´s very insecure. If someone get this token, he always will can send request in your name. The tokens must have a lifetime.
to answer your question how to send API token to mobile app i will recommend you that your mobile apps get a valid token and after refresh it.
Something as this works great to get a token in your app:
if ( thereAreTokenStored() )
{
if (! theTokenStoredIsValid() )
{
$authentication = refreshToken();
}
}
else
{
$authentication = authenticate();
}
To know all this issues I recommend you this book: https://apisyouwonthate.com/ . I learnt a lot of the 'API WORLD' with this book. It will help you to know all you need to create an API in a professional way and will provide the necessary tools and packages to achieve it and save a lot of work. And you will love your API!!
Yes this approach is safe. Additionally you also need to secure your connection to server by using HTTPS with a SSL certificate.
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.