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.
Related
I would like to hide Keycloak's interface from my Customers.
Is it possible to login to Keycloak through an API (specially for Authorization Code grant type), so I can build a React component for example for my customers to login?
Is it possible to build my own Account app, that will interact with Keycloak through an API?
Only my staff should use Keycloak's interface to manage security.
You can redirect your application to the Keycloak login page, and change that login page to have the looks and feel that you desire using Keycloak Custom Themes. To communicate from your Account app to Keycloak Api you can use the Keycloak Admin API.
Yeah, almost every SPA (Angular, React, Vue, ...) developer dreams about replacing of IdP (Keycloak in your case) login screen (because default IdP login is ugly/it doesn't match app style/... and he can build cool login screen on the SPA level :-)).
Sure, it's possible. Switch to Direct Access Grants (Resource Owner Password Credentials Grant) and you can use that. But you will sacrifice security. Let's say you have Google IDP identity brokering, so users will be able to use also own Google account. Will you put your Google credentials to some custom login form, which claims that those credentials will be used only to login and they won't be stolen. I would say no, because app will see your credentials. That is purpose of IdP (OIDC or SAML protocol). It provides user identity to any app (especially for 3rd party apps) without exposing user credentials - that is perfect case for Authorization Code grant type.
So I would say it's possible to use own SPA login form, but it is wrong idea. I would use local app auth in you case.
Second question: you can build own Account based on Account REST API. It is pretty new, so there is no good doc for that and it's only available as an preview feature. New account console should use it - https://www.keycloak.org/2020/09/new-account-console.adoc.html, so you can watch network browser console to see API requests.
Following up on the design outlined in Design for Facebook authentication in an iOS app that also accesses a secured web service, and specifically the concern listed in https://stackoverflow.com/a/12912616/5154090: what would be the mitigation?
Specifically, I have a web server that exposes a REST API which is consumed by a mobile app. I'd like users to authenticate to the server (via the app) using Facebook.
Now, an apparently common flow is for the app to redirect the user to Facebook, where they will login with their credentials. The app will then get a token which it will send to the server, and the server will validate the token using the graph API.
But how can the server make sure that the token really came from the app? Specifically, what's to prevent a malicious app vendor from re-using my app ID? After all, the app ID is hardcoded into the app and can therefore be extracted and used by a malicious app. If users log into that malicious app with Facebook, then the malicious vendor can get tokens with my app ID and can impersonate users of my service.
How can one protect against this?
To summarize for anyone else who happens to contemplate this - there is indeed no way to prevent the client ID from being spoofed. This is one reason that developers are discouraged from using the OAuth implicit flow in native apps as pointed out by Andre D in https://stackoverflow.com/a/17439317/5154090:
the use of the Implicit Flow with native apps is NOT
RECOMMENDED.
(see https://datatracker.ietf.org/doc/html/draft-ietf-oauth-native-apps-09#section-8.5).
In practice, if anyone mounts this attack, then the user will download App A (a malicious app) and will then be asked to authorize App B to make actions on their behalf. As far as I can tell, this is generally the only indication that an attack is taking place.
I have a REST service that my mobile app uses to authenticate when the users click on the Facebook or Google icons.
The service accepts the user's id from the provider and checks if it exists on the database and then issues the access_token to be used for the other methods.
The problem is that I just thought that it could be pretty easy for someone to intercept the calls and discover which service authenticates and what the user id is and then call it with to get a token.
How can I avoid this?
I think you just need to separate the authentication and authorization functions. You can let Google (Google Sign-In) handle authentication. If you follow the API they will securely authenticate the user and send you the token which you can validate.
Once you know who they are for sure, your site can safely authorize that user approriately. For example, they might be an existing user, need to make an account, be an administrator. You can make those authorizations on your site based on the user authenticated by Google (in my example).
Twitter, Facebook and others do the same. Also see OpenID Connect.
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.
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.