2015-02-08 13 views
8

Ich bekomme ein Problem während der Integration externer Anbieter, d. H. Google mit Thinktecture Identity Server v3. Ich bekomme folgenden Fehler: "Die Client-Anwendung ist nicht bekannt oder ist nicht autorisiert." Hat jemand eine Idee über diesen Fehler?Thinktecture Identity Server v3 Google-Provider

+0

Ich habe ein gleiches Problem – akokani

Antwort

0

Sieht aus wie Client (Anwendung, in der Sie die Möglichkeit haben, sich mit Google einzuloggen) ist nicht im Client-Speicher registriert. Könnten Sie bitte Ihre Startkonfiguration anzeigen?

+0

Nicht meine Frage, aber ich habe den gleichen Fehler. Einfügen meines Codes unten, da der Kommentar es nicht halten kann. – Whoever

16

@Wie auch immer, es sieht so aus, als ob die RedirectUri-Werte auf dem Client und dem Server nicht übereinstimmen.

Die RedirectUri-Eigenschaft im Client-Start definiert den URI, der nach der Authentifizierung durch den Identitätsserver aufgerufen wird. Der RedirectUris in der Serverkonfiguration definiert die aufgelisteten zulässigen URIs, die eine Authentifizierung anfordern können. Der Client-Start RedirectUri muss daher in die RedirectUris-Liste des Servers aufgenommen werden.

Sieht aus wie der RedirectUri Ihres Clients derzeit auf den URI des Servers zeigt. Läuft Ihr Client auf Port 46289? Ist dies der Fall, versuchen Sie, den Wert der RedirectUri-Eigenschaft im Clientstart auf https://localhost:46289 zu ändern. Sie können auch versuchen, den redirectUris-Wert des Servers zu ändern, um https statt http zu verwenden, vorausgesetzt, dass Ihr Client wirklich über https erreichbar ist.

Server-Client-Speicher:

public static IEnumerable<Client> Get() 
{ 
    return new[] { 
     new Client { 
      Enabled = true, 
      ClientName = "MVC Client", 
      ClientId = "mvc", 
      Flow = Flows.Implicit, 

      RedirectUris = new List<string>{ 
       "https://localhost:46289/" // client home url 

Client-Startup:

public void Configuration(IAppBuilder app) 
{ 
    ConfigureAuth(app); 
    app.UseCookieAuthentication(new CookieAuthenticationOptions { 
     AuthenticationType = "Cookies"   
    }); 

    app.UseOpenIdConnectAuthentication(
     new OpenIdConnectAuthenticationOptions { 
      Authority = "https://localhost:44300/identity", 
      ClientId = "mvc", 
      RedirectUri = "https://localhost:46289/", //must be in server's Client.RedirectUris 
      ResponseType = "id_token", 

      SignInAsAuthenticationType = "Cookies" 
    }); 
+0

Versuchte beide, Ändern der Umleitung URI und HTTPS, immer noch gleichen Fehler. Auch beim Hinzufügen des Client-bezogenen nugget-Pakets bemerkte es viele Änderungen, die nicht in dem von Thinktecture heruntergeladenen MVC-Beispiel enthalten waren. Nicht sicher, warum sie Server- und Client-Code in die gleiche Stichprobe stellen, ich war mir nicht einmal sicher, wo der Server endet und der Client beginnt, vielleicht etwas Wichtiges woanders verpasst. Ich denke, ich muss das noch einfachere Beispiel ohne MVC zurückgehen, um von vorne zu beginnen. Danke für Ihre Hilfe. – Whoever

+0

Haben Sie sich das Beispiel unter http://identityserver.github.io/Documentation/docs/overview/simpletOAuth.html angesehen? Dies hat einen selbst gehosteten Server, eine Web-API und eine Konsole innerhalb derselben Lösung. I _think_ Ich kam zu meinem aktuellen Beispiel (einem selbst gehosteten Server und einer MVC-Website in IIS, jeweils in ihrer eigenen .sln), indem ich ziemlich viel ein Projekt aus jedem der beiden "Getting Started" -Proben wählte, die unter http: // aufgeführt sind. identityserver.github.io/Documentation/docs/, dann kleinere Änderungen vornehmen, z. B. SSL auf der Serverseite ausschalten und die URIs in der Server/Client-Konfiguration wie oben beschrieben anpassen. – BinaryMash

+0

Ja, ich habe das Schritt für Schritt erledigt. Es hat Server, Web API und Client. Aber im MVC-Beispiel springt es vom Server, um ein Cookie- und openidconnect-Paket hinzuzufügen, und fügt dann [authorize] zum Controller hinzu. Ich konnte nicht sagen, wo der Server endet und der Client beginnt. Ich lasse den Server Teil in einem leeren Projekt, dann erstellt ein separates MVC-Projekt und starten von der Cookie/OpenID-Schritt und bekam diesen Client unbekannter Fehler. Ich bin mir nicht sicher, ob ich das Ganze richtig verstehe. Ich gehe jetzt zurück, um das Web-Hosted-Server-Beispiel und vielleicht einen einzelnen Client zu überprüfen. Es scheint viel zu lernen. – Whoever

2

Ich habe durch das gleiche Problem arbeiten, sondern nur die Authentifizierung gegenüber Identity Server (Google steht als nächstes auf meiner Liste in Angriff zu nehmen) . Ich sah das Problem, weil die Scopes für den Client nicht auf dem Mvc und Server eingerichtet wurden. So lösen Sie das Problem, das ich die Scopes in die Startup-Klasse hinzugefügt (der Mvc-Client) wie folgt:

public class Startup 
{ 
    public void Configuration(IAppBuilder app) 
    { 
     app.UseOpenIdConnectAuthentication(new OpenIdConnectAuthenticationOptions 
     { 
      Authority = "https://localhost:44301", 
      Scope = "openid profile email roles", 
      ClientId = "mvc", 
      RedirectUri = "https://localhost:44300/", 
      ResponseType = "id_token", 

      SignInAsAuthenticationType = "Cookies" 
     }); 

     app.UseCookieAuthentication(new CookieAuthenticationOptions 
     { 
      AuthenticationType = "Cookies" 
     }); 
    } 
} 

..und auch in der Liste der Server der Kunden:

public static class Clients 
{ 
    public static IEnumerable<Client> Get() 
    { 
     return new[] 
     { 
      new Client 
      { 
       Enabled = true, 
       ClientName = "MVC Client", 
       ClientId = "mvc", 
       Flow = Flows.Implicit, 
       RequireConsent = true, 
       RedirectUris = new List<string> 
       { 
        "https://localhost:44300/" 
       }, 
       PostLogoutRedirectUris = new List<string> 
       { 
        "https://localhost:44300/" 
       }, 
       AllowedScopes = new List<string> { 
        Constants.StandardScopes.OpenId, 
        Constants.StandardScopes.Profile, 
        Constants.StandardScopes.Email, 
        Constants.StandardScopes.Roles 
       } 
      } 
     }; 
    } 
} 

In Bezug auf die OPs Frage mit Google: Es lohnt sich, die Bereiche zu überprüfen, die mit denen übereinstimmen, die von Ihrer App in der Google Developer Console unterstützt werden. Es gibt einen guten Posten SO auf unterstützten Bereiche bei Where can I find a list of scopes for Google's OAuth 2.0 API?

Hoffnung, das hilft :)

6

ich dieses Problem hatte. Der RedirectUris-Eintrag in den Servern fast entsprach dem RedirectUri im Client Startup.Configuration; alles außer für den abschließenden Schrägstrich.

https://localhost:46289/ 

nicht das gleiche ist wie

https://localhost:46289 

Wenn ich den Schrägstrich hinzugefügt, erschien meine Login-Seite.

+0

Ich habe den gleichen Fehler gemacht ... :) –

+0

Die Übereinstimmung ist eine exakte String-Übereinstimmung (Groß-/Kleinschreibung nicht beachten) und nicht etwas schlauer mit der Uri-Klasse! – Lukos

0

In meinem Fall war ich nicht vorsichtig und wurde, um die Werte in Startup.cs unter UseOpenIdConnectAuthentication Wechsel (die, was die integrierte Web-Anwendung selbst verbinden verwendet), wenn ich soll die Werte in Clients verändert habe. Get(), das sind die zulässigen Clients, die der Server konfiguriert hat.

Sobald ich diese behoben habe, konnte ich Client und Server in zwei Anwendungen mit nur einigen NuGet-Paketen und UseCookieAuthentication/UseOpenIdConnectAuthentication in der Client-Anwendung trennen.

Sie können den Fehler erhalten, wenn der Client nicht aktiviert ist, Umleitung URI stimmt nicht mit einem in der Liste überein (verwendet keine Groß- und Kleinschreibung), wenn die angeforderten Bereiche nicht in der Liste der zulässigen Bereiche sind Das angeforderte stimmt nicht mit dem überein, was erlaubt ist (Sie können nur eines pro Client haben) und/oder wenn die Client-IDs nicht übereinstimmen.

Verwandte Themen