We want to secure our api using OAuth.
Our server exposes functionalities through APIs. Separate UI applications consume these APIs.
Users use these UI application to access their resources. Since there are only two systems (client and server) involved,
we would like to have 2 legged authorization flow instead of 3legged with redirections. Also we would like have
separate UI (client) application verification once and use this verification code to perform user login and get access token.
Currently we are evaluating spring security framework. Most of spring security tutorials/article talks about 3-legged oAuth with bearer token approach.
I’m not sure if it supports request singing and above mentioned required process. Is there any other open source framework we can use?
Related
I'm developing a microservice in C++ (for low latency reasons), and I'm beginning to dive into OpenID and Keycloak. Developing in C++ means I've almost no library support for OpenID, but I've (hopefully) the all the low level details working (like proper JWT verification). I've to do all the communication flows and redirects myself.
So much as a background. Keep that in mind because I need to know and implement details which usually a library will hide for a developer.
There are three parties in my application:
A web client W
Microserice A
Microservice B
General communication between those three: The web client W could be either a frontend UI or a mobile device using just the API as a service without having any sort of frontend. W connects to microservice A to manipulate and consume data from it. Microservice A exchanges data with microservice B and vice versa. W does not need to know about B.
So far I thought of the following architecture:
For the Web Client to Microservice A communication I'd use dedicated users and clients with access type "Public" in Keycloak to allow user/pw logins
For the Microservice A to Microservice B communication I'd use Access Type Bearer because they never initiate any login
Please advise if you think that does not sound right. My actual question is however what kind of login flow(s) is required and which step there are in between which I may miss:
Is it ok to have an endpoint for the login on microservice A https://servicea.local/login which redirects the requests of the web client to OpenID / Keycloak. E.g. the web client sends username, password, client id and grant typeto the OpenID token request endpoint http://127.0.0.1:8080/auth/realms/somerealm/protocol/openid-connect/token ?
Should the client take the token and add it to all subsequent calls as authorization token?
Should the Microservice implement a callback to retrieve the authorization information?
Should the flow instead be changed for the client to service communication to provide an access code to he service which it exchanges with an access token?
I would aim for an architecture where the role of your C++ APIs is just to verify tokens and serve data.
The client side is a separate solution though, requiring its own code for logging in + dealing with authorization codes and getting tokens. This should not involve your API - so to answer your questions:
Not recommended
Yes
No
No
These days all logins should occur via the system browser, whether you are writing any of these. This client side code is probably not C++ and often requires more work than that to build the API:
Web UI
Mobile UI
Console / Desktop App
If it helps my blog has a lot of write ups and code samples about these flows. In the following post, notice that the API is not called until step 13, once all login processing has been completed by the web client.
OAuth Message Workflow
Authentication (delegating to Keycloak) and then getting Token should be done by your UI by directly contacting keycloak and that token should be passed on from UI to A to B
Here are the OIDC endpoints that keycloak provides
https://www.keycloak.org/docs/latest/server_admin/index.html#keycloak-server-oidc-uri-endpoints
I'm struggling theese days on the possible way to configure an Authentication + authorization system to consume a REST API from a mobile application.
Scenario:
We've developed 3 independent portals for a big customer that serves several users.
To enable a SSO for the 3 portals we've implemented a SAML authentication system using SimpleSAMLphp.
Every portal has a service provider and they make assertion requests against a central IdP.
The IdP checks username and password against a database where passwords are hashed and stored during registration.
After the login, the authorization on the portals is handled by the session on the server, and so far everything was fine.
Now the customer asked us to develop a mobile application that will require the users to login and access several of their protected resources collected during the usage of the 3 portals.
We've decided to develop a frontend application using ionic that will consume a REST API made in node.js that will serve all the data (both protected and unprotected resources).
Now here comes the question: to authorize access to protected resources on the Api we'd like to use JWT to easily achieve a stateless system.
The doubt is how to perform the authentication? We've the opportunity to check the credentials directly against the database skipping the SAML process, otherwise we've to implement a solution where the SSO IdP acts as authentication provider and then when an attempt is successful the API app will get the response from the idp and then issue a signed jwt to the consumer client. Is this second way a common implementation? Is it possible?
What path do you suggest to follow? The first could be very easy to achieve, but since we're using html+js for the app's frontend, if we decide to use the second solution probably in the near future we could recycle some code from the app to modernize some functions on the web portals, maintaining the jwt pattern and consuming the new Api also on the web.
I believe that in this case will be easier to ask a token to the new api using someway the logged in user's data already in the session of the portal. Sounds possible?
I hope that everything was clear, any help will be appreciated!
Thanks
The key goal here is to code your apps in the best way, via
the latest security standards (OAuth 2.0 and Open Id Connect).
SAML is an outdated protocol that is not web / mobile / API friendly, and does not fit with modern coding models.
Sounds like you want to do OAuth but you do not have an OAuth Authorization Server, which is a key part of the solution. If you could migrate to one you would have the best future options for your apps.
OPTION 1
Use the most standard and simple option - but users have to login with a new login screen + credentials:
Mobile or Web UI uses Authorization Flow (PKCE) and redirects to an Authorization Server to sign the user in
Mobile or Web UI receives an access token after login that can be sent to the API
Access token format is most commonly a JWT that the API can validate and identify the user from
The API is not involved in the login or token issuing processes
OPTION 2
Extend option 1 to federate to your SAML Identity Provider - enables users to login in the existing way:
The Authorization Server is configured to trust your SAML based identity provider and to redirect to it during logins
The SAML idp presents a login screen and then posts a SAML token to the Authorization Server
The Authorization Server issues OAuth based tokens based on the SAML token details
OPTION 3
Use a bridging solution (not really recommended but sometimes worth considering if you have no proper authorization server - at least it gets your apps using OAuth tokens):
Mobile or Web UI uses Resource Owner Password Grant and sends credentials to a new OAuth endpoint that you develop
OAuth endpoint provides a /oauth/token endpoint to receive the request
OAuth endpoint checks the credentials against the database - or translates to a SAML request that is forwarded to the IDP
OAuth endpoint does its own issuing of JWT access tokens via a third party library (if credentials are valid)
Web or Mobile UI sends JWT access token to API
API validates received JWT access token
What are some real-world scenarios for 2-legged OAuth?
Is it only applicable for mobile/desktop apps?
2-legged OAuth (aka. the Client Credentials flow in OAuth 2.0) is useful when a client wants to access certain resources without disclosing its primary client credentials to the resource API. The client would authenticate to an Authorization Server to get a derived token that it can present to the resource API to get access to the protected resources.
Getting the token and presenting it is done in a standardized and interoperable way without pestering the resource API with different authentication mechanisms. It also makes revocation of access easier because that is controlled in a centralized fashion on the Authorization Server, independent of the client's primary credentials. See also: How does 2-legged oauth work in OAuth 2.0?
It is applicable across mobile, desktop and web applications although keeping a client secret in mobile and desktop applications is arguably hard so it is most suitable in server-side environments.
A real world scenario is a batch script that fetches data from a remote API and processes it.
2 legged auth is for server to server authentication on behalf of the application with no end-users involved.
For example, your application on Google AppEngine makes a request to Datastore (Database from Google Cloud). This uses 2 legged auth with JWTs.
Instead, if your application makes a request on behalf of the end user to read the user's Google Drive files, 3 legged auth is used.
I am new to security domain, so don't know whether this question is valid to be asked here. I am currently using OpenAM for the security of my web application with J2ee agent, now I find that OpenAM can do authorization with OAUTH as well as on the basis policies defined, now both openam and oauth develops tokens for valid users, and do not share user credential with the application, so how different are the two? My second question is if my application does not support oauth like google and facebook what basic things I need to do to implement oauth into my application.
OpenAM supports OAuth based authorization if that is what your confusion is about. It also supports
1) OpenID Connect
2) SAML
Your application can use either of these to get authorization from OpenAM. Your application can also use the REST APIs for this purpose. The choice is yours.
As far as the tokens go, OAuth tokens are different from OpenAM Tokens. OAuth tokens include
1) refresh_token
2) access_token
The access_token is used for making oauth based calls. However, OpenAM tokens are basically what is there in the cookie or what you get via the REST API.
Regarding your second question, to support OAuth, you would need to use a oauth client library and enable oauth on the server side (in this case OpenAM). This client library would be dependent on the language you choose to write this application.
I am developing web application which consists of a Silverlight application and a REST API. An optional use case is that the customer may also want to integrate with Salesforce. By "integrate" I mean utilize SSO with Salesforce when logging into my application as well as access data via Salesforce's REST API. The current hurdle I can't seem to get over is that SSO uses WS-Federation while Salesforce's REST API uses OAuth 2.0. What is the best way to being these two authentication mechanisms together?
My knee-jerk reaction was for my Federation Provider STS to acquire an OAuth access token from Salesforce and add it as a claim to the security token received from Salesforce's Identity Provider STS, but I think this might require me to write a custom STS. I'd rather not do that. Is there a better way?
This question is old but comes up often, so ...
There is now information on how to do this here
Configuring-SSO-to-SharePoint
This approach uses WS-Fed.