1
votes

We are currently developing an API and IdentityServer with IdentityServer4 github project :

Github repository : https://github.com/IdentityServer/IdentityServer4

Documentation : https://identityserver4.readthedocs.io/en/latest/

And we are thinking about the most efficient and secure way for the API server, or Service Provider (SP) to communicate with the identity Server, or Identity Provider (IdP). We haven't found a lot of informations yet.

This diagram shows us :

enter image description here

That the Service Provider (SP) asks for the Identity Provider (IdP) the User Info (step 5 : User Info retrieval)

(Source : https://www.researchgate.net/figure/OpenID-Connect-Authorization-Code-Flow_fig1_320282638 )

  1. How does the SP asks those informations to the IdP ? Does he, for example, send an HTTP Post "token-info" containing the access token sent by the User ?
  2. If so, how does the IdP understands that this request comes from the SP ?

We suppose we can :

  • use a specific SSL Certificate between the IdP and the SP and validate it somehow,
  • and also RSA Sign the hash of the access token with a certificate known by the IdP ?

We also thought about :

  • registering the SP itself as a specific client of the IdP and a specific claim,
  • This claim is only given to the SP, and allows it to send a request to ask for user information regarding an access token
  1. Furthermore, has the SP the ability to store the informations of the user regarding the access token given and previously sent to the IdP (in a dictionary of AccessToken / User Infos) with a limited amount of time, equal to the duration of the access token ? This would prevent the Service Provider to constantly ask for user information from an access token if a resource is consumed a certain amount of times during the validity of the access token

We can provide code as well, but we believe this problem is mainly an architectural issue.

1
Your question covers, a lot. So perhaps better to ask more fine-grained questions, but I hope my answer is a starting point :-)Tore Nestenius

1 Answers

1
votes

The diagram shows how a user authenticates and gets hold of the access token. The SP is registered in the idP (using clientID/secret). The SP's asks the User(Browser) to authenticate by sending a redirect to the browser.

The SP later when it gets the auth-code, makes a separate request behind the scenes to obtain the real access/id-tokens.

Some simplified code to do this exchange can look like this:

/// <summary>
/// This method is called with the authorization code and state parameter
/// </summary>
/// <param name="code">authorization code generated by the authorization server. This code is relatively short-lived, typically lasting between 1 to 10 minutes depending on the OAuth service.</param>
/// <param name="state"></param>
/// <returns></returns>
[HttpPost]
public IActionResult Callback(string code, string state)
{

    //To be secure then the state parameter should be compared to the state sent in the previous step

    var url = new Url(_openIdSettings.token_endpoint);

    var token = url.PostUrlEncodedAsync(new
    {
        client_id = "authcodeflowclient",       //Id of this client
        client_secret = "mysecret",
        grant_type = "authorization_code",
        code_verifier = code_verifier,
        code = code,
        redirect_uri = "https://localhost:5001/CodeFlow/callback"

    }).ReceiveJson<Token>().Result;

    return View(token);
}

With the received tokens, its up to the client where to store them. In ASP.NET, the ID-token is used to create the user session cookie and then the ID-token is discarded. The access token can also be stored in this cookie, or you can store it in memory or somewhere else. but this all depends on your needs.

Once the SP got the access token, he can pass that token to an API. But, before the API can verify the signature of the token, it first asks the IdP for its public signing key (GET request) and then the API uses it to verify the token signature.

See this page for details about the token signing and keys.