Menu
I have a Jersey based server that I want to secure with OAuth 2.0. There are two paths that I've seen as common:
With support I mean a project that is in continous development, well established community with tutorials, materials and some libraries for clients (web, mobile, server) already available.
Which one is a stronger option? Is there another option or options?
In any case. Is there a good reference material or tutorial to start implementing this?
UPDATE
After few hours of reading and understanding about both the OAuth Providers I had mentioned, I feel Apache Oltu's documentation did not guide me much as there are key components that aren't documented yet, but an example gave me a better picture on how Oltu must be implemented. On the other hand, going through Spring Security's material I got to know that it can still be built on a non-Spring MVC based java project. But there is a limited exposure of implementations/tutorials on Spring Security on a non-Spring based project.
Another approach:
I came up with an architecture that might be more stable and would not care about the implementation details of the inner server(the one already implemented using Jersey). Having a server that is dedicated for security purpose (authorizing, authenticating, storing tokens in its own database, etc) in the middle that acts like a gateway between the outside world and the inner server. It essentially acts a relay and routes the calls, back and forth and ensures that the client knows nothing about the inner server and both the entities communicate with the security server only. I feel this would be the path to move forward as
I appreciate your suggestions or feedbacks on this approach.
707
In OAuth 2.0, the following three parties are involved: The user, who possesses data that is accessed through the API and wants to allow the application to access it. The application, which is to access the data through the API on the user's behalf. The API, which controls and enables access to the user's data.
OAuth is an authorization framework that enables an application or service to obtain limited access to a protected HTTP resource. To use REST APIs with OAuth in Oracle Integration, you need to register your Oracle Integration instance as a trusted application in Oracle Identity Cloud Service.
This article is about OAuth 2.0 authorization scheme integration with ASP.NET MVC REST Web API. REST Web API is a light-weight essential component of web development in order to share the data across multiple client machines or devices e.g. mobile devices, desktop applications or any website.
So, this new scheme of authorization is OAuth 2.0 which is a token based authorization scheme. In this tutorial, I shall demonstrate OAuth 2.0 mechanism to authorize a REST Web API which will also give us the benefit of [Authorize] attribute via OWIN security layer.
Jersey Client Example – Jersey 2 Client API. Jersey 2 client API finds inspiration in the proprietary Jersey 1.x Client API. In this Jersey client example, we will learn to build client API and invoke different REST methods and consume the API results. Table of Contents 1. Jersey Client Maven 2.
Authorization of REST Web API can be done via a specific username/password with the combination of a secret key, but, for this type of authorization scheme, REST Web API access needs to be authenticated per call to the hosting server.
Apache Oltu supports OpenID Connect but its architecture is bad. For example, OpenIdConnectResponse should not be a descendant of OAuthAccessTokenResponse because an OpenID Connect response does not always contain an access token. In addition, the library weirdly contains a GitHub-specific class, GitHubTokenResponse.
Spring Security is famous, but I'm afraid it will never be able to support OpenID Connect. See Issue 619 about the big hurdle for OpenID Connect support.
java-oauth-server and java-resource-server are good examples of Jersey + OAuth 2.0, but they use a commercial backend service, Authlete. (I'm the author of them.)
OpenAM, MITREid Connect, Gluu, Connect2id, and other OAuth 2.0 + OpenID Connect solutions are listed in Libraries, Products, and Tools page of OpenID Foundation.
RFC 6749 (The OAuth 2.0 Authorization Framework) distinguishes an authorization server from a resource server. In short, an authorization server is a server that issues an access token, and a resource server is a server that responds to requests which come along with an access token.
For a resource server, API Gateway is one of the recent design patterns. Amazon, CA Technologies, IBM, Oracle and other companies provide API Gateway solutions. API Gateway architecture may be close to your idea. Some API Gateway solutions verify access tokens in their own ways (because the solutions issue access tokens by themselves) and other solutions just delegate access token verification to an external server (because the solutions don't have a mechanism to issue access tokens). For example, Amazon API Gateway is an example that delegates access token verification to an external server, which Amazon has named custom authorizer. See the following for further information about custom authorizer.
If an authorization server provides an introspection API (such as RFC 7662) that you can use query information about an access token, your resource server implementation may be able to replace (plug-out and add) an authorization server to refer to comparatively easily.
For an athorization server, gateway-style solutions are rare. It's because such a solution must expose all the functionalities required to implement an authorization server as Web APIs. Authlete is such a solution but I don't know others.
142
I think, it's far simplier to use the oauth connectors that are implemented inside jersey itself! Have you considered using jersey own OAuth (already linked inside jersey) server / client ? https://eclipse-ee4j.github.io/jersey.github.io/documentation/latest/security.html#d0e13146
Please take a look to :
16.3.2. OAuth 2 Support
hope helped. :)
37
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
