Migrieren von Google OpenID zu OpenID Connect: openid_id stimmt nicht überein

Question

Ich habe mit dem Prozess der Migration von Google OpenID zu OpenID Connect mit OAuth 2.0 begonnen, wie in der Documentation beschrieben. Ich kann den Workflow zum Abrufen der openid_id und sub innerhalb des id_token vom Token-Endpunkt erfolgreich abschließen, aber wenn dies der Fall ist, stimmt die openid_id nicht mit der vorhandenen Kennung überein, die wir in unserem System haben. Verhindern, dass ich den vorhandenen Benutzer der neuen ID zuordnen und verhindern kann, dass sich der Benutzer bei unserer Anwendung anmeldet (oder sich möglicherweise als jemand anderen anmelden kann). Die ID hat das richtige Format, passt aber nicht zusammen.

Ich habe den openid.realm-Parameter auf unser existierendes openid.realm eingestellt und die Umleitung so eingestellt, wie in der Dokumentation vorgeschlagen. Dies geschieht sowohl lokal als auch in unseren von Azure gehosteten Umgebungen. Ich benutze das JWT.JsonWebToken, um das id_token zu dekodieren, aber ich habe auch verifiziert, dass es richtig dekodiert wurde, indem ich den Web-gehosteten Decoder unter google: JWT Decoder benutze, und ich habe den selben OpenID Identifier gefunden, der nicht mit dem übereinstimmt für diesen Benutzer. Ich sollte auch beachten, dass ich versucht habe, den Profilumfang hinzuzufügen, aber das hat keinen Unterschied gemacht.

Wir verwenden DotNetOpenAuth.OpenId für unser ursprüngliches System, also glaube ich nicht, dass das Problem dort liegt. Ich habe den ClaimedIdentifier untersucht, der Teil der Antwort ist, und er stimmt mit dem überein, was wir in unserem System für openId speichern, damit wir ihn nicht falsch speichern.

Unten ist das, was wir verwenden, um den Uri für die Auth-Anfrage zu generieren. Es ist hauptsächlich eine modifizierte Version des DotNetOpenAuth.GoogleOAuth2-Clients.

protected static Uri GetServiceLoginUrl(Uri returnUrl) 
    { 
     var state = string.IsNullOrEmpty(returnUrl.Query) ? string.Empty : returnUrl.Query.Substring(1); 

     return BuildUri(AuthorizationEndpoint, new NameValueCollection 
      { 
       { "response_type", "code" }, 
       { "client_id", AppId }, 
       { "scope", "openid" }, 
       { "prompt", "select_account"}, 
       { "openid.realm", CloudServiceConfiguration.GetDNSName() }, 
       { "redirect_uri", returnUrl.GetLeftPart(UriPartial.Path) }, 
       { "state", state }, 
      }); 
    } 

private static Uri BuildUri(string baseUri, NameValueCollection queryParameters) 
     { 
      var q = HttpUtility.ParseQueryString(string.Empty); 
      q.Add(queryParameters); 
      var builder = new UriBuilder(baseUri) { Query = q.ToString() }; 
      return builder.Uri; 
     } 

Und hier ist das, was wir die Anforderung an den Token-Endpunkt zu erzeugen, verwenden.

protected static Tuple<string, string> GetAuthTokens(Uri returnUrl, string authorizationCode) 
    { 
     var postData = HttpUtility.ParseQueryString(string.Empty); 
     postData.Add(new NameValueCollection 
      { 
       { "grant_type", "authorization_code" }, 
       { "code", authorizationCode }, 
       { "client_id", AppId }, 
       { "client_secret", AppSecret }, 
       { "redirect_uri", returnUrl.GetLeftPart(UriPartial.Path) }, 
      }); 

     var webRequest = (HttpWebRequest)WebRequest.Create(TokenEndpoint); 

     webRequest.Method = "POST"; 
     webRequest.ContentType = "application/x-www-form-urlencoded"; 

     using (var s = webRequest.GetRequestStream()) 
     using (var sw = new StreamWriter(s)) 
      sw.Write(postData.ToString()); 

     using (var webResponse = webRequest.GetResponse()) 
     { 
      var responseStream = webResponse.GetResponseStream(); 
      if (responseStream == null) 
       return null; 

      using (var reader = new StreamReader(responseStream)) 
      { 
       var response = reader.ReadToEnd(); 
       var json = JObject.Parse(response); 
       var accessToken = json.Value<string>("access_token"); 
       var idToken = json.Value<string>("id_token"); 
       return new Tuple<string,string>(accessToken,idToken); 
      } 
     } 
    } 

Answer 1

Bitte stellen Sie sicher, dass Sie GENAU der gleiche openid.realm Wert während der Migration verwenden fließt, wie Sie während des Anfangs OpenID2 fließt verwendet: jede Nichtübereinstimmung in diesen Werten (auch ein fehlenden Schrägstrich Zeichen) führt zu völlig unterschiedliche OpenID-Identifier-Werte.