OpenID Connect 1st and 3rd-party Relying Parties Architecture

1
votes

I am writing a REST-API for X1 and X2 application of Company-X.

In order for user to access and login to X1 and X2 they should have a valid Company-X account, like how you need google account to use gmail and google+. In short, X1 and X2 has no authentication in itself, it use Company-X Identity Provider (IP) to have authenticate and have a session.

In OpenID Connect (OIDC) terms, X1 and X2 will be the Relying Party (RP). X1 is a User-agent, X2 is a server. Company-X IP contains authorization server and the resources (protected REST-API).

  • Am I right to choose those grant types? (See legend of the diagram)

  • Is this the recommended architecture for this case? (1st party application with centralized account for login and will IP for 3rd party app in the future)

    enter image description here

1
oauth-2.0openid-connect

1 Answers

2
votes

The selection of grant types is primarily performed by looking into the following aspects:

  1. The type of the client application
  2. What resources the client application wants to access

In the first point one of the things to consider is the environment in which the client application runs:

  • browser-based -> implicit grant
  • server-side -> authorization code grant and/or client credentials grant
  • native application -> mostly implicit grant, but authorization code grant may also be considered

Based on this and what you described, the selection of implicit grant for RP X1 seems appropriate.

In relation to RP X2 it's not so clear-cut and we should review it from the perspective of which resources this application wants to access. Being on the server-side this application is capable of maintaining secrets and as such eligible for client credentials, however, this grant is suitable when the application wants to access resources that are associated to the application itself and not to a specific user.

If this application is going to access resources associated to a Company-X user account then it should use the authorization code grant.

The next diagrams illustrate this substantial difference between the client credentials grant and all the other grants. As you'll notice, there is no separate resource owner involved (in theory the resource owner is the client application itself).

Client Credentials

OAuth2 Client Credentials Grant Diagram

(source: Client Credentials Grant)

Authorization Code Grant

OAuth2 Authorization Code Grant Diagram

(source: Authorization Code Grant)

In relation to the architecture from my perspective it seems to be the correct approach. It uses public standards and caters for your requirements so I highly doubt it there are better alternatives. The big issue with authentication systems is not the design phase, it's the implementation itself, especially considering that making it "work" takes about 20% of the effort and the remaining 80% is ensuring that you didn't mess up.