i want to create an Api for my own mobile App to access data that is stored in a MySQL-Database. However i read a lot of articles about the 3-legged OAuth approach and i think this is not the solution i'am looking for. When i understand it correctly the 3-legged approach is more usable when for instance i create a new twitter client and want to use the twitter Api.
But my app is not a third party app, my app and the website incl. the database are from me. So i assume, that the user starts the app enters his user id and password, then the api has a function that checks whether userid/pw are correct and sends "true" as a result back to the app. The app then offers the user the possibility to access the functions for which a login is necessary. So the user should not be redirected to a website and "allow" the access to userid/pw.
If i understand it correctly the 2-legged approach is more likely for my purpose. But i am confused by this also. I assume that the user enters his id and pw, these credentials are looked up in the database by the web service a token will be looked up in the database for this user and will be send to the app. Additionally an app-token is saved in the app from the beginning and will be send with the request also. The app will save this user-token from the DB internally and will use this token everytime the user does something with the web service. With every request to the web service the token will be send to the service and the service checks whether the token is a valid one otherwise an error is send to the app.
I looked up this example:
http://code.google.com/p/oauth-php/wiki/ConsumerHowTo#Two-legged_OAuth
But there is nothing mentioned that the userid/pw from the user are looked up in the database...
Can anybody explain how i can solve this?
Two legged OAuth is similar to Client-Server. It is a client app requesting full access to the data from a server. The client would have full access to all data allowed by it's credentials regardless of which user is accessing the client
Three legged OAuth is a User-Client-Server. It is a Client requesting to get access to the User's data from a server. The Client would only have access to that an authorized user's data (until the user revokes access).
Related
I am writing backend for a mobile app where the login info (user), details of the app and everything used in the mobile app will be on the server side.
That's how I have written the app flow:
The created users are saved on the server side via registration API
The newly created users send credentials and after authentication, I generate a dynamic token which is shared with the user for rest of the API calls
For every other call that a user makes, the token is authenticated and then the response is generated.
Each login generates a new token so at a time the same user won't be able to use the same account on 2 different mobiles. Since on valid login, a new token will be generated for API usage.
Whole of the communication takes place over SSL so everything is already encrypted. I want to know the security threats that would be saved by OUATH 2 in this scenario.
P.S Please write your thoughts in comments if you down-vote this question. Will highly appreciate it.
I am developing a backend for mobile app. I have developed a user authentication module where, the app will be sending the username and password as basic auth and if the user is authenticated I will sent back a jwt token which can be used in the rest of the requests.
On the client side, once after a user is logged in, the app shows him a feeds screen which contains some data.
Now do I need to seperate these two APIs? Like once a user is logged in successfully, he will be sent back the jwt token and well some user details. Should I sent the data which is required for the dashboard screen as well as a response for login? In that the case the app will get datas in a single api request (login) and doest have to make another call to my API.
Is this a right approach?
Ideally it should be kept seperately but I think that depends. If making that single request is (and will ever be) the only thing the application does, I see no reason for making 2 requests. You can simplify things by making just 1 request.
But, if your application is going to be extended or if its already got other features i think it is best to keep them seperate. Since then you'll have more flexibility with your application.
Yes ,You should separate those two authentication and dashboard REST API as-
It could be possible that there should be more client app using your Rest API in future and they may not require dashboard data.However you can have mechanism to share user detail in authentication API itself as you are anyway authenticating user .However share access token in authentication api along with it's expiration timestamp .Some of Client app which are using your REST API might have use case of autologout from app based on accesstoken get expire.In such case expiration time would help.
I managed to implement the Google Play Services API in my Cordova app (game). The game now sends the Google Play Services Player ID to my server when a person connects.
I am making a system that validates a user's permissions and sends them some data (an image from my server) if the permissions check out. So, I have the Player ID, but that isn't enough to validate that they are who they say they are.
I don't understand how to use Oauth2 to validate a user is who they say they are.
Stop me when I go off track:
Presumably, I would need a one-time token from them that I could then validate with, eh, "something", and then run a PHP validation function with that token and the "something" to validate that they are who they say they are.
I'm not sure how to request the token without having Google Play Services create an authorization window within my app, or what the code for any of it is. I saw some Oauth 2 things in PHP but they are positively gigantic things. I'm looking for something that can clearly explain how I can validate the user and a couple of lines of code for implementing it.
Ok, I think I figured it out. Basic concept...
1) User asks for access token for Google Play Services Player API. (requires an authorization dialog)
2) User sends access token to server.
3) Server sends access token to Google Play Player API.
4) If successful, server authenticates user.
https://developers.google.com/games/services/web/api/players/get
Edit: The above applies to HTTP only. Unfortunately, as far as I can tell, there is no built-in Android / Google Play mechanism to get an authorization code, only an access token.
I'm working on an API and considering using OAuth (3-legged approach) for authentication and authorisation.
This is the basic idea:
In order for clients (mobile app or web app), to use this RESTful API the user will have to be logged in using identity providers/servers such as Google, Facebook e.t.c
Essentially 3 parties will be interacting here:
The mobile / web app: The one trying to access my API
The API: The site that contains data for the app to run
The identity server: The site that will allow the user to login in order to access the API
Now, the way that I understand this process (assuming I do). This would be the flow (summarised):
The user will try to access data from the API (consumer);
The consumer finds that the user is not logged in;
The user gets a page (with service provider buttons such as Login with Google);
The user clicks the button, and the service provider returns a login form;
The user logs in;
The service provider returns a page asking for specific permissions;
The user grants permission;
The service provider returns an access token to the user;
The user uses the access token to try the request again to the consumer (API);
The consumer takes the token and verifies it against the service provider;
The consumer grants access to the user.
First
Is this process correct (on a higher level), or have I completely misunderstood the whole thing. If it is not correct: Could you offer some tweaks?
Second
After this whole process. How does the consumer communicate with the user? Will I have to be passing around a token on every request made (between the mobile app and the API)? Or can I just use the user details from the service provider to identify the user?
Third
How exactly does the consumer (API) verifies the token provided by the user against the server? Is this already implemented in OAuth, or will I have to do it myself?
Forth and last
In terms of implementation, what would be the difference between the client (mobile app / web app) and the consumer (API)?
I'm new to this, and I am trying to implement it in PHP (the API). If you have any references to PHP code (sample implementations) or external resources, I'd really appreciate it :-)
I am also new for oauth but I'll try to help.
First you could look here for appropriate libraries which could help.
As for me your oauth flow is correct. A good explanations you can also find here.
Keep in mind that authorization server should return an authorization code which you use for obtaining access token.
So your questions:
1) Follow the second link and there - "Authorization Code".
2) With every request to you API you should send your access token. Something like
http://<your api>?access_token=7f813af1-381d-4dd7-b70b-b6a8399b2c00
3) Just use the libraries from the first link. I hope that they have already implemented this. :)
4)Can't exactly understand what you mean. Your client must be able to obtain access token, store it and send it with requests. Your API server must be able to receive access token from client, and give access to api if the access token is correct.
I have been doing research on this Oauth concept and I am still very confused about this concept. One of my main questions is how does one register with a google account or a twitter account.
For example, lets say in order to register to my website, you must provide a Username/Password/Email/GroupName. If you register through my website, than you can provide those fields very easily. However let's say the user wants to register through google. How would those fields populate?
From my understanding once you register with your google credentials, you are redirected to a page on my website where you fill in the required fields. I am not sure if this is correct. Can anyone help me understand this more?
Basically OAuth works like this (depending on the version these points consist of multiple steps):
You redirect the user to a provider, where he logs in
The user is redirected back to you and you receive an access token
Using this access token you can then request the users data from the provider. Typically the providers provide a call which you can use to ask for the user's email address, full name and a (provider-specific) user id, but that is not part of OAuth.
How you now use this information to handle that user as if he logged in to your site is then completely on your own. You probably want to create a new user object on your side each time you see a new user id.
There are couple of basic concepts that needs some clarity before one can understand how a new user registration happens using OAuth2. These are:
Resource Owner (You, the human)
Identity Provider (Google, Facebook, Twitter, etc.)
Resource Server (Same as Identity provider, or some other service)
Resources (Things you want access to)
Client app (The app you are using to access those things)
For new user registration, you will follow the same sequence of client app requesting authorization to be granted access to the resources. This will trigger a login page, user logs in, authorization code is created (by the IdP) and sent back to the client app. The client app exchanges this code for an access token (some encryption signing is involved, read up the documentation - basically allowing client app to prove its own identify).
This access token is then used to request access to resources - in this case, the new user profile. This could be name, email, picture etc. Use this to create a new row in your client apps profile database. A new user account is created.
Then for subsequent logins, the client app will use this access token to validate its life with the Google Auth server - and then create a local session/cookie to login the user.
Hope this is clear.