Given that I would create an OAUTH2 authentication server.
Given that I would to have separate resource servers, exposing REST APIs.
What are the best communication practies between the authentication server and the API servers?
To explain OAUTH2 server would be a proxy authenticating the user and forwarding requests to different API servers, that are not third party, but under the hood of the OAUTH2 proxy, relying on it to know the agent (user) requesting for the given command\query.
The simplest would be that the authentication server will forward the user id (that is stored with ACL rules also on each API server) under a secure connection, and that access would be restricted to request forwarded from authetication server to resource API servers.
The auth server would in this case forward the user id, but this seems suceptible to mand in the middle attack (altought firewall on API servers would be configured to accept requests only from the authentication server).
Another problem would be compromission of the OAUTH proxy, giving automaticly grant to any request coming from it.
Are there ready solution and patterns to deal with this scenario?
Thanks!
Check the User Account and Authentication Service (UAA) from CloudFoundry. Maybe will help you. It is also available as a stand-alone OAuth2 server.
API Documentation, GitHub
Related
I'm building a microservice based REST API and a native SPA Web Frontend for an application.
The API should be protected using OAuth2.0 to allow for other clients in the future. It should use the Authorization Code Flow ideally with Proof Key for Code Exchange (PKCE)
As I understand it I need to run my own OAuth Auth Server that's managing the API Clients and generating access tokens, etc.
Also I need my own Authentication/IAM service with it's own fronted for user login and client authorization granting. This service is the place the users login credentials are ultimately checked against a backend. That last part should be flexible and the backend might be an LDAP server in some private cloud deployment.
These components (Auth Server and IAM servicve) are outside of the OAuth scope but appear, correct me if I'm wrong, to be required if I'm running my own API for my own users.
However creating these services myself appears to be more work than I appreciate besides the obvious security risks involved.
I read about auth0 and okta but I'm not sure if they are suited for my use case with the application potentially deployed in private cloud.
I also thought about running Hydra (OAuth Server) and Kratos (IAM) by ory but I'm not sure if this is adding too many dependencys to my project.
Isn't there an easy way to secure an API with OAuth that deals with the Auth Server and the IAM that's good for small projects?!
I understand that keycloak has built-in clients and we add the users later on.
But in general, what is the difference between a client and a user in Keycloak?
According to the Keycloak documentation
User - Users are entities that are able to log into your system
Client - Clients are entities that can request Keycloak to authenticate a user. Most
often, clients are applications and services that want to use Keycloak to secure
themselves and provide a single sign-on solution. Clients can also be entities that
just want to request identity information or an access token so that they can
securely invoke other services on the network that are secured by Keycloak
In short words, not only for keycloak but for OAuth and OpenId Connect too, a client represents a resource which some users can access. The built-in clients for keycloak represent some resources for keycloak itself.
Clients and users are two completely different constructs in keycloak.
In plain English, client is an application. Example for an application could be a e.g. yelp.com or any mobile application. Client can be a simple REST API. Keycloak's built in clients are for keycloak internal use, But any user-defined application has to be registered as a client in keycloak.
Users are the one which authenticate via keycloak to gain access to these applications/clients. Users are stored in keycloak DB or any externally hosted LDAP but synced with keycloak.
I'm designing a REST service in Node, and I have a plan for authentication and authorization -- but I'm not certain whether there's an unforeseen flaw in the design.
I have a central API server exposed to the Internet. The server also hosts a manager application (which communicates via AJAX), but is authenticated separately from the API, per requirement.
My initial thoughts are to have the server authenticate the user with a login form, then send the user a token (all over HTTPS, of course) that can be sent with each request to the API server for authentication and authorization.
Are there any flaws with this methodology?
I saw the word "endpoint" many times in OAuth documents.. However, I still don't know what does this word really mean.. Does anyone have ideas about this?
The OAuth 2.0 Authorization Framework
The authorization process utilizes two authorization server endpoints
(HTTP resources):
Authorization endpoint - used by the client to obtain
authorization from the resource owner via user-agent redirection.
Token endpoint - used by the client to exchange an
authorization
grant for an access token, typically with client authentication.
Its basically the HTTP web address of the authentication server. It could probably be server addresses depending upon how its worked. The first is for requesting access of the user the second could be for granting access to the application. this probably depends upon how the Authentication server is set up.
OAuth endpoints are the URLs you use to make OAuth authentication requests to Server. You need to use the correct OAuth endpoint when issuing authentication requests in your application. The primary OAuth endpoints depend upon the system you are trying to access.
Example Google has two end points:
Request access of user:
https://accounts.google.com/o/oauth2
Exchange tokens
https://accounts.google.com/o/oauth2/token
We are designing security for a green field project with a UI web module (Spring MVC) - the client, and a RESTful services web module (CXF) - the server, to be deployed as separate war files in the same Websphere app server. The system should be secured with Spring Security, authenticating against LDAP and authorizing against a database. We have been looking for the best solution to share the security context between the 2 apps, so a user can authenticate in the web UI and invoke its AJAX calls to the secured RESTful services. Options found:
OAuth: seems overkill for our requirements, introduces a fairly complex authentication process, and reportedly some enterprise integration issues
CAS: would amount to setting up an enterprise SSO solution, something beyond the scope of our engagement
Container-based (Websphere) security, although not recommended by Spring Security, and we're not clear if this could provide a solution to our specific needs
We're looking for a simpler solution. How can we propagate the Security Context between the 2 apps? Should we implement authentication in the UI web app, then persist sessions in the DB, for the RESTful services to lookup? Can CXF provide a solution? We read many threads about generating a 'security token' that can be passed around, but how can this be done exactly with Spring Security, and is it safe enough?
Looking forward to any thoughts or advice.
You want to be able to perform the REST web services on the server on behalf the user authenticated in UI web module.
The requirements you described called SingleSignOn.
The simplest way to do it is passing the HTTP header with the user name during REST WS calls.
(I hope your REST client allows to do it).
To do it in secure way use one of the following:
Encrypt the user name in REST client and decrypt it in REST server
Ensure that the header is sent from the local host (since your application deployed on the same container)
Therefore, protect both application using SpringSecurity authenticate against LDAP.
In the first application (Rest Client) use regular Form Authentication
In the second application (Rest Server) add the your own PreAuthenticatedProcessingFilter:
http://static.springsource.org/spring-security/site/docs/3.1.x/reference/springsecurity-single.html#d0e6167
Edited
The “Authentication” is the process of verifying of a principal’s identity.
In our case both REST Client (Spring MVC application) and REST server (CXF application) verify an identity against LDAP. LDAP “says” OK or Not. LDAP is a user repository. It stateless and does not remember the previous states. It should be kept in applications.
According to my understanding, a user will not access directly to REST server – the user always access REST Client. Therefore, when the user access REST Client he/ she provides a user name and a password and REST Client authenticate against LDAP. So, if REST Client access REST server the user is authenticated and REST Client knows his name.
So, if request come to REST server with a user header name - REST server for sure knows that the user was authenticated and it should not authenticate it again against LDAP.
(The header should be passed in the secured way as described above).
Rest Server should take the user name, to access to LDAP and to collect related user information without providing of the user password (since the user already authenticated).