I'm working on a RESTful API, that works as backend for a mobile application.
The underlying system is based on Jersey and Jetty server, but my question is more generic (for any JaX-RS compliant system).
I'm looking for a standard solution to secure it. I read about many answers talking about JWT, tokens, ... and OAuth.
But all solutions except OAuth do not have a Standard and neither any implementation apart from some basic examples on github.
I'm concern as OAuth seems a good solution for third party access on your API but I think is a great overhead for straight access & tokenization, from a Mobile app or a Website AJAX. Is hard for me to accept that is the only available solution.
Here I'm asking, am I wrong about OAuth (beeing designed for third party access)? or other access solutions are not available (eg opensourced) as they are only custom made for the specific purpose?
My scenario requirements:
Token should be self certified (eg JWT) so a proxy/load balancer can filter out a not signed one, before reaching the endpoint.
No need for a token/renew system as we have a distributed cache holding a SESSION and therefore a missing session mean that authorization expired/was revoked.
The second one, may not be true as if we issue a certificate to an App for 1 year, and revoke it after 1 hour. This token may be still used by an attacker to "frustrate" our cache for 1 year.
Related
I'm struggling with these concepts and having trouble finding good resources on the web.
We are looking for ways to switch out custom implementations tightly integrated into our application for standards based authentication and authorization.
Our scenario is as follows:
A simple web site (may be an app in the nearby future)
A user must log in or otherwise gain access (i.e. there's no "guest" content or other things you can do as a guest)
The site uses its own web services (REST and/or SOAP) on the backend, but it might use 3rd party web services or exposes its own services as 3rd party services for other applications
Authentication may very well be done by an external provider: Users carry a smartcard and we'd like to have one simple identity provider which reads the smartcard information and sends it back to my simple web site (so I know who the user is and what his role is for instance)
Other sites might use other methods of authentication (simple username/password for instance), so we might need a configurable Service Provider??
I'm currently looking at OAuth (2) to implement for authorizing use of our REST Services (is it also useful for SOAP?) to our web site, perhaps with a simple "Client Credentials Grant" type.
But for authentication, I'm still none the wiser. There is OpenID, but is it easy enough to build your own OpenID Identity Provider? There is Shibboleth, but it seems to have a steep learning curve for doing custom stuff. And I've looked at just building something from scratch based on the SAML Authentication Request Protocol with an HTTP Post binding. Are there any other options?
Please keep in mind that we want to be flexible with our authentication. For a certain site, we might want to do the smartcard thing, but for another maybe simple username/password login with LDAP.
If it's helpful still, I personally thought about doing it myself, then discovered a bunch of third parties. I compared (5/18/2015):
Auth0
AuthRocket
UserApp
DailyCred
Conclusion for me was Auth0, because while all the features are very similar, it felt the most legitimate, as in it's not a start-up that might disappear in a few months. Now, the reason that was super important for me was because login is a foundational requirement, so I need to believe as a customer that the Authentication as a Service will be up for as long as I will be.
Here's the full comparison story:
https://medium.com/#bsemaj/authentication-as-a-service-comparison-5-quick-lessons-for-b2b-businesses-e7587275824c
Updated based on questions from #user18044 below
If a user is authenticated in two different web applications via 2 different SAML-based identity providers, and one of the applications needs to request data from a web API exposed by the other application, would it be possible to call the web API methods securely by virtue of the user's current authenticated status in both applications without separately securing the API methods via an API level authentication protocol such as OAUTH? Note that both applications are owned and operated by my company and share the same 2nd level domains and user base, even though the identity servers are different (one is legacy).
Some further information: Application A is a portal application that is going to host widgets using data supplied from Application B. Application A will only communicate with application B via a web API exposed by application B. Currently application B does not expose a web API (except internally to the application itself). This is new functionality that will need to be added to application B. Application A will use Okta as its SSO. Our lead architect's proposal is to continue to use a custom legacy IDP server that we developed internally based around using the dk.nita.saml20 DLL. They are both SAML based I believe, but I don't think they could share the same identity token without some retrofitting. But this is hitting the limits of my knowledge on the topic of authentication. :) I think our architect's plan was to have the user authenticate separately using the two different identity providers and then only secure the web API using CORS, his reasoning being that since the user is already known and authenticated to use application B, that there wouldn't be any security implications in allowing application A to call application B's web api methods, as the user should be authenticated in application B. This seems quirky to me, in that I can imagine a lot of browser redirects happening that might not be transparent to the user, but other than that, I'm just trying to figure out where the security holes might lie, because it feels to me that there would be some.
I know that this approach would not be considered a best practice, however with that being said, I really want to understand why not. Are there security implications? Would it even work? And if so, are there any "gotchas" or things to consider during implementation?
To reiterate, our lead architect is proposing this solution, and it is failing my gut check, but I don't know enough on the topic to be able to justify my position or else to feel comfortable enough to accept his. Hoping some security experts out there could enlighten me.
It's hard to answer without knowing more on how your current applications and APIs are secured exactly. Do the web application and its API have the same relying party identifier (i.e. can the same token be used to authenticate against both)?
If both web applications use the WS-Federation protocol to authenticate users, then most likely the SAML token will be stored in cookies that were set when the identity provider posted the token back to the application.
You do not have access to these cookies from JavaScript. If the web API that belongs to application B uses the same cookie based authentication mechanism, you could use this provided you allow for cross origin resource sharing.
If your web API uses something like a bearer token authentication scheme (like OAuth) or has a different relying party id in the STS, this would obviously not work.
I think the reason this fails your gut check is because you are basically accessing the web API in a way a cross-site request forgery attack would do it.
A problem I see with this approach is that if the user is not authenticated with the other web application, then the call to your API will also fail.
I agree with user18044 as far as it being based on a cross-site request forgery attack and the security between applications. Is it true that if User X has access to App A, that they will have access to App B and vice versa? If that is not the case, then each application will need to be authenticated separately...and it won't be a SSO. I found these links that might be helpful in your situation.
https://stackoverflow.com/questions/5583460/how-to-implement-secure-single-sign-on-across-various-web-apps
https://developer.salesforce.com/page/Implementing_Single_Sign-On_Across_Multiple_Organizations
A typical recommendation for securing a REST API is to use HTTP Basic Authentication over SSL. My question is, should HTTP Basic Authentication only be used to authenticate the client (ie. the app accessing the API), or can it also be used to authenticate the user (the consumer of the app)?
It seems most APIs have to deal with both, as almost all web services employ some sort of user accounts. Just consider Twitter or Vimeo—there are public resources, and there are private (user specific) resources.
It seems logical that a simple REST API could do both client and user authentication at the same time using using HTTP Basic Authentication (over SSL).
Is this a good design?
By authenticate the client you probably mean the usage of API Key, this mechanism is used to track the concrete application/client. The second thing is that it gives you the possibility to disable the application by disabling the key, for example when client's author removes his account from the service. If you want to make your API public then it is a good idea.
But you need to remember that it gives you no real protection, everybody can download the client and extract that key.
I would not recommend to use Basic Authentication for API authentication. When it comes to authentication then you should consider that the application (client) developer has to implement its side of the authentication, too. Part of that is not only authentication itself but also how to get credentials and even much more than that.
I recommend to make use of an established authentication standard that ships with client libraries for the most popular programming languages. Those libraries make it much more likely that developers are going to adapt your API, because they reduce implementation effort on the client side.
Another important reason for using authentication standards is that they make developers (and others) more confident in the security of your authentication system. Those standards have been audited by experts and their weaknesses and strengths are well known and documented. It is unlikely that you are going to develop a nearly as solid authentication flow unless you are a security expert :-).
The most established standard in this field is OAuth but you can find alternatives by searching for "oauth alternatives".
How does OAuth help you with your problem setting?
In OAuth 2, the application client has to obtain an access token for a user before accessing any protected resource. To get an access token, the application must authenticate itself with its application credentials. Depending on the use-case (e.g. 3rd party, mobile) this is done in different ways that are defined by the OAuth standard.
An access token should not only represent a user but also which operations may be used on what resources (permissions). A user may grant different permissions to different applications so this information must somehow be linked to the token.
How to achieve such a semantic for access tokens however is not part of OAuth - it just defines the flow of how to obtain access tokens. Therefor, the implementation of the access token semantic is usually application specific.
You can implement such token semantic by storing a link between an access tokens and its permissions in your backend when you create the access token. The permissions may either be stored for every user-application combination or just for every application, depending on how fine-granular you want things to be.
Then, each time that an access token is processed by the API, you fetch this information and check whether the user has sufficient permissions to access the resource and to perform the desired operation.
Another option is to put the permission information into the access token and to sign or encrypt the token. When you receive the access token, you verify or decrypt it and use the permissions that are stored in the access token to make your decision. You may want to have a look on Json Web Tokens (JWT) on how to accomplish that.
The benefit of the later solution is better scalability and less effort during backend implementation. The downside of it are potentially larger requests (especially with RSA encryption) and less control over tokens.
I am in the early stages of planning (in particular for the security) of a REST API through which a mobile application authenticates and then sends data to be stored in (and also to be retrieved from) the Joomla website/database. It's basically an application-to-application authentication.
I plan to use the API for own internal use which means that the otherwise important aspect of "making it easy for third party developers/API users" is not as important. My main concern is that I of course want to prevent that illicit information can be injected through such API calls. At some stage I might also be asked by external auditors about how this security aspect is properly covered - hence I better be prepared from the start... ;)
SSL is planned to be used for client/server communication and the API will also use a username/pw for authentication, But does anyone have an opinion about (and maybe experience with) using OAuth as a security layer? I do not mean using user's social media pw for the Joomla login, I mean implementing oAuth on the Joomla Component side (i.e. the Joomla side REST API).
Thanks
This is exactly what we have done at our organization. It would have been nice to follow some existing OAuth (I assume OAuth 2) implementation using Joomla but I don't think it exists other than vanilla php implementation. We used this active project but built our own from scratch. This project takes into account all Grants and I suspect if you are doing mobile app authentication like us you will stick to the Resource Owner Password Credentials Grant. So it really depends on what you are doing.
So the first part was authenticating with Joomla from our mobile app. Here is a post on the start of that. With that we followed the spec RF6749 to follow the convention needed and produced the proper Bearer Token etc.
Then it was a simple matter of doing what was needed for the mobile apps with the REST APIs.
I'm over simplifying it (especially since I'm recommending going through the RFC carefully) but once you know how to authenticate with Joomla, your sailing. IMO.
Suppose I have a front-end application that wants to fetch some data from a back-end service. (I do.) The service will need to verify that the end-user is authenticated, that it is authorized to use the service and possibly filter the returned data based on the user's privileges. In my case, both the front-end app and the back-end service relies on Azure ACS for authentication.
Ideally the front-end would like to act on the behalf of the authenticated user, which sounds like a good fit for using an ActAs token (as specified in WS-Trust). However, it turns out that ACS does not currently support ActAs.
A workaround could be to use the actual bearer token (the bootstrap token in the front-end app) to authenticate to the back-end service. It's not hard to do, but would it be a bad idea for some reason?
From your front-end app, you could certainly pass along the identity data of the end user by either sending the token as is or sending the attributes from it. Both have issues. For the former, if it's also encrypted, the front- and back-ends will have to share the private key needed to decrypt it; they will also have to share audience restrictions, etc. in order for the back-end to consider the token valid for it. In other words, the front- and back-ends will be ONE relying party, not two. Might not be a problem, but be aware. In the latter case, you end up sending user data in a proprietay way which could increase integration and maintenance costs over time. In both cases, you can authenticate the front-end app to the back-end using some other type of credential, e.g., a certificate used at the transport level and, thus, forming a trusted subsystem between them.
One thing that I would suggest you consider instead is OAuth 2. From this blog post, it seems to me that ACS supports it (though I don't have any first hand experience w/ it). The truely wonderful thing about OAuth 2 is that it bakes delegation in, and is NO WHERE near as complex as ActAs in WS-Trust. The net result is the same, i.e., the back-end service will have info about the calling service and the end user, but the amount of effort to get it setup in incomparable. The tokens will still be bearer tokens, but you can mitigate that to a degree by using SSL. Beyond SSL, you can put some additional measures in place, but the best, IMO, would be if Microsoft did something in ACS like Google has done w/ their Access Tokens for service accounts which uses asymmetric keys that are chained up to a PKI. (BTW, for all I know, Microsoft may have already done something like that; if so, you're set.)
Anyway, HTH!