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?

Answer 1

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