Suppose I have a Web Service API defined and would like to implement OAuth Server to provide access to third-party mobile application and my own mobile application.
As these two types of application(internal/external) will try to access my API, what are the possible mechanisms that my authentication server differentiate them?
As an Example, Consider a Facebook app and Lyft (External).While login to facebook through Lyft, fb recognizes it as third-party app and ask for permission level but in Facebook(Internal) app they don't ask permission level. How do they do it?
*Please correct me, if I am wrong here.
OAuth 2.0 differentiates between clients/applications by granting them their own set of client credentials in the form of an identifier and a shared key, respectively named client_id and client_secret.
Related
I am currently building an API for my native App and want to implement the OAuth 2.0 protocol for authentication. If I take a look at companies like Instagram, Facebook or Twitter I wonder how they are handling the authentication process of their own native App (not third-party).
So Instagram for example is using the OAuth 2.0 protocol to protect their API endpoints (here). Related to their developer platform they offer you - as a third-party developer - the possibility to use their API and authenticate your own App via Server-side (Explicit) or Implicit flow. All of these flows require the user to authenticate via an In-App browser (or system browser).
Like I said before, I am wondering how these Apps are handling the authentication in their own Apps. The user doesn't get redirected to any browser to authenticate. They could use the Explicit flow and store the client_id and client_secret for example in Keychain (iOS). But Instagram is telling third-party developers "You should never pass or store your client_id secret onto a client. For these situations there is the Implicit Authentication Flow.".
I don't want the user to get redirected in my own App. The user should be able to use a login/signup form within the native App.
Does anyone have an idea or insides on how Instagram etc. are doing it? I am really curious and appreciate any helpful answer. :)
My app logic (Android, iOS and Web) is all written in my server.
Since things got complicated, I decided to build my server as a REST web service so querying it will contain logic in the header.
My login flow is pretty simple, and I somehow tried to copy from Facebook API:
The user login to Facebook.
The user receive a Facebook access token
The access token is sent to my server with some other identifiers
The server checks with Facebook that the access token is valid with Facebook and that the other identifiers match the ones on Facebook.
The server returns an access token to the user, which he should use in each query until it expires.
The problem is that I didn't add any other restrictions like endpoints limitations (scopes) and stuff like this, so an access token generated by my server grant you access to each part of my api.
I think that inventing the wheel here will be foolish, so I'm looking for a framework or a generic solution that will allow me to add logic to the access tokens in a simple way.
I read about OAuth, but my concern that its more about user sharing with other users, but I only want to use it is login flow and scope protector.
Is it possible with OAuth ? Are there alternative to OAuth ?
That's possible with OAuth 2.0 and in fact one of the objectives: you may issue and use access tokens that have particular "scopes" (an OAuth 2.0 concept) associated to them that could relate to permissions that the client has (e.g. read/write, API A, API B).
But you need to issue your own access tokens from your own Authorization Server. You could allow users to login to that Authorization Server with their Facebook account.
Is there a way of passing username/ password to Google Apps IDP and get a response as to whether a username/ password pair is correct?
I know I can use OAuth for authorization and access user data but note that I want to check if his credentials itself are valid. OAuth for sure will not work for me. I need a way to directly query Google Apps' IDP particularly not to use it and access something else.
I wish to use this to customize the Google's standard login page itself. OAuth doesn't allow me to do that.
Short answer: no.
Google actively tries to prevent the scenario that you describe because it would mean that Google users hand over their Google credentials to your application, aka. phishing.
That precludes branding of the Google login pages as well since it would make it harder for users to verify that they actually type in their credentials on a login page provided by Google.
As said in the other answer, Google Signin with OpenID Connect (built on top of OAuth 2.0) is the standardized way to offer users login to your application with their Google account.
Google (Apps) accounts can be used as an OpenID identity provider. By implementing your app as as a relying party, you could authenticate your users based on their Google accounts. Much like stackoverlow Google login: http://code.google.com/googleapps/domain/sso/openid_reference_implementation.html
With SAML SSO, Google acts as a relying party. While its possible to use provisioning API and clientLogin, this is not supported and is possibly against Google Apps ToS.
I'm building a web service for use as an api component in web sites or apps built by others.
I am building a set of functionality that my clients can use on their sites for their users, but which are served by my application.
One of these services is user login. I intend to support multiple types of logins, and provide the client application a user token once the user is logged in. So the client application only has to implement one login interface, but they get a variety of oauth2 strategies for it.
To make this work with their google or facebook accounts, they would have to provide my app with their application id and secret key. Entering a secret key on someone else's site, even for integrating with your own site seems dangerous. They call it a "secret" key for a reason.
I have found one web service which seems to be doing something similar to what I am planning to do:
https://www.authic.com/documentation/google_oauth2
They have a configuration page for client accounts where the user enters oauth2 credentials to enable the Authic oauth2 login pages on behalf of the client app.
What are the security concerns to be aware of with this kind of service, and can the client app use a service like this safely? If it can be used safely, what is required for safe use? I think the app doing the oauth2 interface would be able to do other things on behalf of the client app, since it has an app secret, and the client app owners would have to trust that this was not happening.
The alternative to this strategy seems to be using my own application id with oauth2, and having the client apps redirect to my app's login page. Then the user will see the oauth2 permissions page with my app's logo instead of the app they were intending to log in to.
I am creating a REST API server. For each app I have provided API key and secret. Example apps are Web app, mobile app any other app who want to use my api service. Now my API service will also need user authentication. How do I implement that? I have already done app authentication using hmac signature generation. Now I need help on implementing user authentication on those apps.
I can recommend you use OAuth or OAuth2 concept because it's standardized and widely adopted. You will be also able allow users to login with Facebook, Google account, etc.