Sign Up to our social questions and Answers Engine to ask questions, answer people’s questions, and connect with other people.
Login to our social questions & Answers Engine to ask questions answer people’s questions & connect with other people.
Lost your password? Please enter your email address. You will receive a link and will create a new password via email.
Please briefly explain why you feel this question should be reported.
Please briefly explain why you feel this answer should be reported.
Please briefly explain why you feel this user should be reported.
I’m developing API – No problems here
The API will be used by my mobile client to communicate with the Webservice.
My problem is I don’t know what authentication system so that people can login in the native app and the API knows which user is sending requests.
I can make it OAuth based, but my app is not third party and i want user to goto a webpage etc and i want them to login inside the app and be able to send requests as authenicated user.
What is 2-legged and 3-legged authenication
If your API is available over SSL you can simply go for HTTP Basic Authentication.
But the benefit of OAuth in your scenario is that it works reasonably securely even without a secure transport layer such as SSL, the specification is such that it prevents malicious “replays” of a request, that having been said, without SSL, individual requests can be eavesdropped upon.
You could implement xAuth, which is basically OAuth but with much easier user authentication. Each API request will still have to be signed, but you can get an access token by sending username and password. This seems like a promising alternative for you.
2-legged authentication is basically for application to application authorization. Basically two applications exchanging API services without a specific end user being involved. 2 legged authorization bypasses the authorization step, and basically immediately provisions an access token.
3-legged involves a user authorizing a third party application (a consumer) to access its resources with a service provider. This scheme involves a temporary token (request token) that the end user must verify, thereby provisioning an access token.