Microsoft OAuth2-Authentifizierung gibt Refresh-Token nicht zurück

Question

Ich füge Microsoft OneDrive-Unterstützung zu einem Produkt hinzu, das mein Arbeitgeber an andere Unternehmen verkauft. Als ich meine Design- und Prototyping-Phase durchging, verwendete ich eine Anwendungs-ID, die ich über eine Anwendungsregistrierung erhalten hatte, die ich mit meinem persönlichen Konto erstellt hatte. Jetzt arbeite ich daran, den Code tatsächlich in unser Produkt einzufügen und verwende eine Anwendungs-ID, die durch eine Anwendungsregistrierung erhalten wurde, die (von jemand anderem) über unser Office365-Firmenkonto vorgenommen wurde.

Ich habe einen Unterschied in den Ergebnissen der Authentifizierungsabfragen zwischen diesen beiden Anwendungsregistrierungen. Ich versuche die Ursache aufzuspüren und ich hoffe, dass jemand hier helfen kann.

Als ich die Registrierung von meinem persönlichen Konto aus verwendete, erhielt ich alle Datenelemente aus der /token-URL, die in der Microsoft-Online-Dokumentation dokumentiert waren. Als ich zur Verwendung der Registrierung von unserem Unternehmenskonto wechselte, änderte nichts in dem Code außer der Anwendungs-ID, ich bekomme den refresh_token Wert nicht. Ich habe für beide Tests dieselben Anmeldedaten verwendet.

Hier ist die Information, wenn meine persönliche Registrierung mit:

Url: https://login.microsoftonline.com/common/oauth2/v2.0/token

Anfrage Körper: grant_type=authorization_code&client_id={XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX}&code=XXXXXXXXXXXXXX...XXXXXXXXXXXXXXXX

Request Response:

{ 
    "token_type":"Bearer", 
    "scope":"https://graph.microsoft.com/files.readwrite.all", 
    "expires_in":3599, 
    "ext_expires_in":0, 
    "access_token":"XXXXXXXXXXXXXX...XXXXXXXXXXXXXXXX", 
    "refresh_token":"XXXXXXXXXXXXXX...XXXXXXXXXXXXXXXX" 
} 

Hier ist die Information, wenn unsere Registrierung mit :

Url: https://login.microsoftonline.com/common/oauth2/v2.0/token

Anfrage Körper: grant_type=authorization_code&client_id={YYYYYYYY-YYYY-YYYY-YYYY-YYYYYYYYYYYY}&code=YYYYYYYYYYYYYY...YYYYYYYYYYYYYYY

Request Response:

{ 
    "token_type":"Bearer", 
    "scope":"https://graph.microsoft.com/files.readwrite.all", 
    "expires_in":3599, 
    "ext_expires_in":0, 
    "access_token":"YYYYYYYYYYYYYY...YYYYYYYYYYYYYYY" 
} 

Andere als die Werte für client_id und code, das einzige, was anders ist, ist die Registrierung der Anwendung (ein ein mit persönliches Konto und das andere mit einem Office365-Konto). Was könnte die Ursache dafür sein? Fehlt bei der Registrierung über unser Firmenkonto etwas?

Ich habe keine Berechtigungen, um die Firmenregistrierung anzuzeigen, also kann ich nicht vergleichen, was sie es versus, was ich in meiner persönlichen Registrierung hatte. Ich gab ihnen alle relevanten Informationen, aber ich weiß nicht, ob sie alles getan haben, was ich gefragt habe.

Answer 1

Die Microsoft-Dokumentation ist ziemlich unklar. Ihre Online-Dienste haben viele Iterationen durchlaufen, und dies führt zu einer Menge von Restdaten herumliegen. Wenn ich den Zugriff auf beide Anwendungen innerhalb von Office365 widerrief und beide erneut von Grund auf neu authentifizierte, fehlte bei beiden Anrufen der Wert refresh_token in der Antwort aus dem Anruf /token.

Ich habe es geschafft, die Stücke aus der Microsoft- und OpenID-Dokumentation zusammenzusetzen, um die Antwort zu finden. In der anfänglichen Autorisierungsanforderung wurde der Fehler durch den Aufruf von https://login.microsoftonline.com/common/oauth2/v2.0/authorize behoben, durch den offline_access zum Abfragezeichenfolgenparameter scope hinzugefügt wurde.

Auf der App-Registrierungsseite muss nichts hinzugefügt oder geändert werden.Wenn dieser neue Bereich hinzugefügt wird, wird dem Benutzer auch angezeigt, dass die Anwendung offline Zugriff auf die Daten anfordert. Diese Schrittfolge aktiviert die Rückgabe des Werts refresh_token. Warum es in erster Linie dort war, ist ohne Angabe von immer noch ein Geheimnis.