CODEWITHSUNDEEP
authenticationoauthgoogle-oauthopenidopenid-connect
Sato
Sato

Reputation: 8602

Can multiple services use one Relying Party?

My company are going to use OpenID connect and use Google as Identity Provider, I have read OpenID connect document these days, still have some questions, first one is we have multiple services, should we create Relying Party for each service, or can use create one Relying Party for all our services?

For example, company site: company.com, and 3 completely different services: service1.com, service2.com,service3.com, so should we provide 3 Relying Party: auth.service1.com, auth.service2.com,auth.service3.com, so if user click login button on service1 which points to auth.service1.com will redirect user to account.google.com.

Or can we just provide 1 Relying Party, auth.company.com for all 3 services?

Upvotes: 1

Views: 909

Answers (2)

Yonkee
Yonkee

Reputation: 1883

Yes. You just need some custom code in your RP to manage requests from multiple apps if logic differs. This also provides a place to abstract logic away from clients and avoid code duplication.

Upvotes: 0

Kavindu Dodanduwa
Kavindu Dodanduwa

Reputation: 13059

First understand what relying party means in OpenID Connect (OIDC) context. From the specification,

Relying Party (RP)

OAuth 2.0 Client application requiring End-User Authentication and Claims from an OpenID Provider.

RP is a OAuth 2.0 client. So if you check OAuth 2.0 specification for it's definition, you find below definition (extracted, see the full description from link),

An application making protected resource requests on behalf of the resource owner and with its authorization

As I see, answer relies in those highlighted points.

  • Can each services can be categorise as an application independently? Do they have independent behaviour from each other?
  • How authorisation constraints act on these services. Do they have independent functionalities? How they represent the end user (resource owner) ?

So if you consider each service as an independent application and have its own authorisation constraints, then I think they should consider going for different RPs. Else if these services are dependent with each other and internally use same authorisation constraints, then go for a single RP to represent them.

Regardless, it's difficult to answer correctly without exactly knowing what those services actually do.

Upvotes: 1

Related Questions