7

I am a bit lost with the overflow of information and I need some guidance on the best way I can support providing APIs access only to trusted clients.

Current environment:

We currently have a centralized server that handles user authentication/authorization via Apache Shiro.

We have in-house APIs that communicate internally with the centralized server to authenticate and manage tokens. (Thus enabling SSO).

Communication between our client applications and APIs are secured over SSL.
Token-based authentication is used.

Target:

Our target is to allow 3rd party applications and APIs to communicate with our centralized authentication server. But our main concern is phishing, as we only want "valid" parties to communicate with us, and preferably disallow exposing the authentication information on the 3rd party's side.

Questions:

1- What is the best way to implement such an architecture? Should we go ahead with OAuth? If yes, is there a good way to integrate it with Shiro?

2- Would OAuth do its job well on Mobile applications as well? (e.g Restrict access to REST API unless the application is trusted)

3- Is there an OAuth provider library I can use with Java, or is OAuth simply a "standard" that I have to implement myself? (Such as, for example, implementing RESTful APIs)

4- Is SSO easily support with OAuth?

Sorry for vague questions. I just need general guidance and advice.

SiN
  • 3,704
  • 2
  • 31
  • 36
  • 2) My question is - why OAuth should not work on mobile devices? :) I don't see any reason, why it shouldn't work there.. – Martin Dvoracek May 10 '13 at 13:40
  • Is Shibboleth an option? It looks like that also integrates with mobile apps, and has a somewhat more consistent API than oAuth does. [see this SO question about it](http://stackoverflow.com/questions/1935011/integrating-iphone-application-with-shibboleth) – David May 10 '13 at 13:45
  • Is it a requirement that your users be able to grant/deny access to their data by these third party apps? – Perception May 10 '13 at 13:48
  • Dworza, if the mobile application sends username and password immediately to provider, it means we're not following correct standards, right? – SiN May 10 '13 at 14:26
  • Perception, there is a requirement at least to allow/deny permissions per Application, and user should be able to grand/deny access to the whole application after seeing the permissions before "allowing" the application to use his ID. Maybe something similar to Facebook... – SiN May 10 '13 at 14:27

2 Answers2

2
  1. Mobile apps work perfectly fine with OAuth.
  2. SSO can be enabled using OAuth.

Some info on how to set up a OAuth server/provider - How would an efficient OAuth2.0 server / provider work?

As you say, you need to ask the user for authorize an app (accept/deny permissions that the app asks for) - perfect use case for OAuth 2.0.

Feel free to follow up if you need more insight on how OAuth works.

PS - No idea about integration with Shiro.

Community
  • 1
  • 1
divyanshm
  • 6,600
  • 7
  • 43
  • 72
2

Here are my answers in order,

  1. OAuth 2.0 is the best fit for you. I would say you should go for OAuth.
  2. Definitely yes.
  3. There are libraries. Apache Oltu and Google client library.
  4. OpenID Connect specification which is built on top of OAuth can be used to implement SSO.
divyanshm
  • 6,600
  • 7
  • 43
  • 72
SureshAtt
  • 1,891
  • 2
  • 17
  • 22
  • The documentation for Google client library specifies that " this library is an easy-to-use and efficient Java client library for accessing Google APIs using JSON and OAuth 2.0. ". I am lost, I thought this would be a library for implementing my own OAuth provider ? – SiN May 15 '13 at 11:30
  • Not yet... Still evaluating Spring Security OAuth. Would OAuth 1.0 work, or should I go ahead with 2.0 immediately ? – SiN May 17 '13 at 14:00
  • Go with OAuth 2.0 which is the new version and is capable of doing many more. – SureshAtt May 22 '13 at 02:19