Are there documented best practices when federating identity to a third party using OIDC?

Question

We are creating an OpenId Provider (using Identity Server 4) that has the ability to federate authentication to other IdPs based on email (eg, we first ask for email and then determine how to authenticate you, potentially by redirecting you to another OpenId Provider). I'm looking for documented best practices on this scenario, especially when dealing with sessions. Some examples:

1. When we are authenticating locally (not federating), we want to store a session cookie at the IdP to enable SSO scenarios. However, in the case of federation, we perhaps should not store cookies and should instead always redirect to the third-party IdP (who may or may not have cookies).
2. If the user is federated and the client requests a refresh token, we should request a refresh token from the third party IdP and give that to the client. In turn, when issuing new access tokens based on the refresh token, we should validate that the refresh token is still valid at the third party IdP.

Flows like these would give the third party IdP better control over security and session parameters specific to their needs. However, I have been unable to find documentation, standards or RFCs detailing these or other recommended flows when federating from one OpenId Provider to another.

Answer 1

Feel you, there is almost nothing documented to be an idp, but you can find a lot on how to be a sp.

As far as I understand federated identity, when you use idp1 and federate to idp2, idp1 acts as a client so yes, you should delegate almost everything to idp2 (request tokens, validate them, etc).

I also agree with

we should not store cookies and should instead always redirect to the third-party IdP.

that should have cookies stored to mantain SSO.