Using SAML/OpenID Connect to implement SSO for two websites. How to authenticate Swing client?

Question

I am trying to implement SSO for two websites and have currently looked into SAML and OpenID Connect. But I need to authenticate a Swing based desktop client using the same credentials.

I have read about the implicit flow of OpenID Connect but it still needs to open a browser it seems.

SAML Enhanced Client or Proxy profile which seems to solve this kind of problem seems to not be implemented by most idps I have tried out. (Only Shibboleth supports it and the documentation for Shibboleth is not that good).

What kind of solution works for this problem?
Are there any other SSO mechanisms that support both native and web apps?
Are there workarounds for OpenID Connect/SAML for this kind of problem?
Would it be a good idea to just expose a REST API that authenticates the Swing client using the same credentials as the SSO IdP?

Design a simple custom token to authenticate: http://www.thebuzzmedia.com/designing-a-secure-rest-api-without-oauth-authentication/ — lcryder, May 26 '15 at 12:02
The desktop app you are talking about is managed by the same company as the identity provider right ? Another way of saying this : do you have control over both the codebase of the identity provider AND desktop app ? — Michael Técourt, Jul 31 '15 at 14:00

score 2 · Answer 1 · edited May 23 '17 at 11:53

OpenID Connect tries to solve the problem of sharing user authentication between two parties : the identity provider (OP) and a client.

This is not clearly stated in the OIDC docs, but based on my experience OIDC doesn't try to solve how you authenticate your own users accross different platforms (web, mobile/desktop).

That's one of the very few valid use cases for the OAuth 2.0 "Resource Owner Password Credentials grant", where the client exchanges the user credentials for a token.

Here you are inside your own system, your mobile/desktop application cannot be considered a third party, it only provides a trusted way for the user to send you its credentials.
You can make sure the app does not store them since you have control over the codebase.

EDIT : The mobile app instances can share (unless you manage to dynamically assign client IDs) a client ID/secret that cannot be kept confidential. It makes up a really thin client authentication layer, trying to make sure that the requests do come from your mobile/desktop application :

POST /oauth/token HTTP/1.1
Authorization: Basic ${BASE64_ENCODED_CLIENTID_CLIENTSECRET}
  grant_type=password&
  username=${USERNAME}&
  password=${PASSWORD}

Some people dislike that it specifies how to authenticate a user, and some companies may have additional credentials than username+password, for example when using 2-factor authentication. Also, some people used the ROPC grant wrong, as it is only valid inside an organization, allowing a client to request your own user credentials is killing the point of having an SSO/authorization protocol.

OIDC is still OAuth 2.0, which means you are free to implement your own "user credentials" flow to obtain an access token + ID Token from your desktop/mobile app. It's outside the scope of OIDC though.

BTW, SAML was created at a time when mobile apps were not really in the picture :

SAML 2.0 was ratified as an OASIS Standard in March 2005

Using SAML/OpenID Connect to implement SSO for two websites. How to authenticate Swing client?

1 Answers1