Laden...

Wie arbeite ich mit ASP.NET MVC 4.7.2, Office 365 AD und Rollen?

Erstellt von Peter Bucher vor 3 Jahren Letzter Beitrag vor 3 Jahren 2.141 Views
Peter Bucher Themenstarter:in
5.941 Beiträge seit 2005
vor 3 Jahren
Wie arbeite ich mit ASP.NET MVC 4.7.2, Office 365 AD und Rollen?

Hallo zusammen

Ich muss abklären wie Authentifizierunt / Authorisierung mit Rollen über Office 365 AD in ASP.NET MVC 4.7.2 zu implementieren ist.

So wie ich das sehe, ist der Einstiegspunkt hier?
=> https://docs.microsoft.com/en-us/azure/active-directory/develop/quickstart-create-new-tenant

Ist jetzt alles "Identity"?
Wie kann ich eine x.IsInRole("xyz") Implementierung umsetzen?
Es besteht schon eine Implementierung mit einer eigenen Identity (Klasse) und einem RoleProvider, kann ich das relativ einfach migrieren?
Bzw. Rollen im AD hinterlegen, die ich dann so abfragen kann?

Danke für Ansatzpunkte.

Grüsse Peter

--
Microsoft MVP - Visual Developer ASP / ASP.NET, Switzerland 2007 - 2011

16.807 Beiträge seit 2008
vor 3 Jahren

Die neue Plattform nennt sich Microsoft Identity; richtig.

Ist jetzt alles "Identity"?

Verstehe die Frage nicht.

Wie kann ich eine x.IsInRole("xyz") Implementierung umsetzen?

Das kommt drauf an, was Du machen willst.

Moderne Authorisierung interessiert die Rolle nicht, sondern die Claims.

Das bedeutet:

  • Der User hat Claims
  • Die Rolle hat Claims
  • Der User hat eine Rolle
  • Der User bekommt neben seinen eigenen Claims am AuthN-Prozess auch die Claims über die zugehörige Rollen.

Ich weiß nicht mehr wie bei ASP.NET MVC das damals aussah, aber bei der ASP.NET Core Identity ist das alles in der Form auch schon eingebaut.
Prinzipiell ist das aber alles die Claims-based identity.

In der Applikation fragst Du dann nur die Claims ab.
Diese bekommst Du entsprechend über die OAuth Scopes.

Da der Token jedoch nur eine gewisse Größe haben kann gibt es die Empfehlung mit Policies zu arbeiten, sodass Policies die Claims prüfen und Du diese im Token nicht mitführen musst.

Acht bei der Doku darauf, dass ADAL die alte Auth-API ist.
Die neue Auth-API ist die MSAL. Neue App-Regstrierungen und gewisse AuthN-Level forcieren den MSAL (zB. die Graph API).

Peter Bucher Themenstarter:in
5.941 Beiträge seit 2005
vor 3 Jahren

Hallo Abt

Danke für deine Antwort. Phu, ich habe nicht gerne so dicke komplexe APIs. Das meinte ich mit meiner Frage, ob man heute als mit diesem Identity Framework machen muss.

Offensichtlich ist das so, auch das Aufgebau mit Claims oder Policy ist scheinbar nötig und eine Alternative gibt es nicht?

Werde dann wohl nach der offiziellen Anleitung gehen und weiss dass ich das migrieren kann, super!

Acht bei der Doku darauf, dass ADAL die alte Auth-API ist.
Die neue Auth-API ist die MSAL. Neue App-Regstrierungen und gewisse AuthN-Level forcieren den MSAL (zB. die Graph API).

Gibts ein Lexikon für AuthN-Level, MSAL, etc? 😃 LOL

edit:
Dann muss ich sowieso OWIN einbinden und habe dann mein Problem der fehlenden Startup Klasse nicht mehr 😃

Danke und Grüsse
Peter

--
Microsoft MVP - Visual Developer ASP / ASP.NET, Switzerland 2007 - 2011

Peter Bucher Themenstarter:in
5.941 Beiträge seit 2005
vor 3 Jahren

--
Microsoft MVP - Visual Developer ASP / ASP.NET, Switzerland 2007 - 2011

16.807 Beiträge seit 2008
vor 3 Jahren

Das meinte ich mit meiner Frage, ob man heute als mit diesem Identity Framework machen muss.

Müssen nicht, aber nimmt Dir enorm viel ab.
Ich nutze das Framework gerne, auch wenn ich die Stores meistens vollständig ersetze.

Offensichtlich ist das so, auch das Aufgebau mit Claims oder Policy ist scheinbar nötig und eine Alternative gibt es nicht?

Ist der quasi-Standard seit Jahren beim Thema Application Security; daher ja - kommst quasi nicht drum rum.

Gibts ein Lexikon für AuthN-Level, MSAL, etc? 😃 LOL

Einstieg ist umfangreich, wirklich umfangreich 😃

Peter Bucher Themenstarter:in
5.941 Beiträge seit 2005
vor 3 Jahren

Hallo Abt

Habe jetzt Owin (Identity) eingebaut nach der Anleitung, die securityGroups weitergeleitet und alles konfiguriert. Kann jetzt bei Microsoft auf meinen Benutzer klicken, aber nachher will er zurück auf meine Seite und bringt einen 404.

Folgendes ist die RedirectUri die überall drinsteht:

<add key="RedirectUri" value="https://localhost/dashboard"/>

Hier die Login Actionmethode:


        [HttpGet]
        public ActionResult Login(string ReturnUrl = "")
        {
            if (!Request.IsAuthenticated)
            {
                HttpContext.GetOwinContext().Authentication.Challenge(
                    new AuthenticationProperties { RedirectUri = "https://localhost/dashboard" },
                    OpenIdConnectAuthenticationDefaults.AuthenticationType);
            }

Und er bringt einen 404. Wenn ich auf F5 klicke, will er noch einmal einen POST absetzen. Ich frage mich gerade, wo das Problem liegt? Bei localhost?

Fehlermeldung:
Angeforderter URL: /dashboard

Danke und Grüsse
Peter

--
Microsoft MVP - Visual Developer ASP / ASP.NET, Switzerland 2007 - 2011

16.807 Beiträge seit 2008
vor 3 Jahren

Der OAuth-Callback zurück zu Deiner Anwendung erfolgt via POST.
Alle Callback-URLs (auch Redirect) müssen korrekt (auch mit zusätzlichem Slash) konfiguriert werden.

IIRC macht localhost da gerne Probleme.
Abhilfe: ne local domain über hostnames setzen.

PS: Owin ist nicht Identity.
Beide Dinge sind unabhängig voneinander 😉

Peter Bucher Themenstarter:in
5.941 Beiträge seit 2005
vor 3 Jahren

Hallo Abt

Ah, Post Redirect haha. Ganz was neues.
Ich habe nirgendwo was von einer Post-CallBack Url gelesen bezüglich Identity. Wo finde ich denn diese Infos? Scheinbar bin blind.

Identity ist der Nachfolger von Membership. Und Owin ist für die Authentifizierung Server/Client.

Aber da gibt es scheinbar Token based (für Apps) und nicht Token based?
So richtig schön übersichtlich ist das also überhaupt nicht.

Im Beispiel finde ich keine Route, die für einen "Post Redirect" genutzt wird.

Grüsse

--
Microsoft MVP - Visual Developer ASP / ASP.NET, Switzerland 2007 - 2011

16.807 Beiträge seit 2008
vor 3 Jahren

Ist Owin also nur der OpenId Connector?

OWIN hat mit Identity nichts am Hut.

OWIN steht für Open Web Interface for .NET entfernt die harte Bindung von ASP.NET MVC zu IIS und entkoppelt ihn; quasi das, was Du unter dem entkoppelten Pipeline-Verhalten (Middlewares etc..) bei ASP.NET Core hast.
Dank OWIN konnte MVC neben IIS auch auf Apache und Co rennen.

Project Katana kam dann in die OWIN Welt, weil das den Schnittstellen-Umgang erleichtert hat und so man zB. auch Services in OWIN registrieren konnte (das, was heute ConfigureServices bei Core ist).

Der OpenID Connector verwendet vermutlich Katana, um die Services in OWIN zu registrieren.
OWIN ist aber herzlich egal, ob Du OpenID verwendest oder nicht. OWIN ist nur für die Laufzeit der Anwendung und Verarbeitung der Requests (führt die registrierten Middlewares aus) zuständig.

Ah, Post Redirect haha. Ganz was neues.

Redirect != Callback.

Callbacks sind Post, Redirect nicht.
Trotzdem muss in der App Registration auch der Redirect korrekt hinterlegt sein.

In Deinem Beispiel ist der Redirect laut Web.config einfach auf die Root-Url.

Die Callback-Implementierung ist Teil der Middleware und muss nicht selbst implementiert werden.

Peter Bucher Themenstarter:in
5.941 Beiträge seit 2005
vor 3 Jahren

Hi Abt

Danke für deine Ausführungen!

Callbacks sind Post, Redirect nicht.
Trotzdem muss in der App Registration auch der Redirect korrekt hinterlegt sein.

In
>
ist der Redirect laut Web.config einfach auf die Root-Url.

Die Callback-Implementierung ist Teil der Middleware und muss nicht selbst implementiert werden.

Ja mir ist dieser Unterschied schon geläufig, nur heisst es in der Doku "RedirectUri" und auch die Beschreibung hört sich überhaupt nicht nach einem Callback an. Die RedirectUri ist 1:1 eingestellt in Azure. Auch die Root Url. Ich nehme an da funkt sonst noch was dazwischen, sodass es die Route nicht findet 😦.

Danke für den Tipp, dass Callback direkt an die interne API geht. Ich sondere mal aus.

Grüsse

--
Microsoft MVP - Visual Developer ASP / ASP.NET, Switzerland 2007 - 2011

Peter Bucher Themenstarter:in
5.941 Beiträge seit 2005
vor 3 Jahren

Hi Abt

Alle Callback-URLs (auch Redirect) müssen korrekt (auch mit zusätzlichem Slash) konfiguriert werden.

Sorry, das habe ich wohl übersehen. Ich schaue mal, ob der zusätzliche Slash da ist! 😃

Danke und Grüsse

--
Microsoft MVP - Visual Developer ASP / ASP.NET, Switzerland 2007 - 2011

Peter Bucher Themenstarter:in
5.941 Beiträge seit 2005
vor 3 Jahren

Hallo Abt

So, jetzt bin ich einen Schritt weiter. Die API greift.
Darf ich ohne Probleme den implicitFlow verwenden, wo man die id_token in Azure aktivieren muss?

Siehe:

Scheint ja für Webanwendungen zu sein, oder Mobileanwendungen. Aber da es ja eine externe Auth / Author ist, müsste das passen, oder?

Doch nicht:

If you are developing a Web application that includes a backend, and consuming an API from its backend code, the implicit flow is also not a good fit. Other grants give you far more power. For example, the OAuth2 client credentials grant provides the ability to obtain tokens that reflect the permissions assigned to the application itself, as opposed to user delegations. This means the client has the ability to maintain programmatic access to resources even when a user is not actively engaged in a session, and so on. Not only that, but such grants give higher security guarantees. For instance, access tokens never transit through the user browser, they don't risk being saved in the browser history, and so on. The client application can also perform strong authentication when requesting a token.

=> https://docs.microsoft.com/en-gb/azure/active-directory/azuread-dev/v1-oauth2-client-creds-grant-flow

Oh jesses 😁

Grüsse

--
Microsoft MVP - Visual Developer ASP / ASP.NET, Switzerland 2007 - 2011

16.807 Beiträge seit 2008
vor 3 Jahren

Darf ich ohne Probleme den implicitFlow verwenden, wo man die id_token in Azure aktivieren muss?

implicitFlow ist nen relativ unsicherer Flow; man sollte alternativ Authorization Code Flow verwenden.
Sind aber Flows für Anwendungen; ja.

Aber es gibt unterschiedliche Flows für Server Side WebApps, Client Apps, Mobile Apps, APIs...
Musst den richtigen Flow für Deine Anforderungen nehmen.

Peter Bucher Themenstarter:in
5.941 Beiträge seit 2005
vor 3 Jahren

Hi Abt

Das ist doch mal ein Wort. Dann richte ich mich an Authorization Flow, dankeschön! 😃

Grüsse

--
Microsoft MVP - Visual Developer ASP / ASP.NET, Switzerland 2007 - 2011

16.807 Beiträge seit 2008
vor 3 Jahren

Vermutlich kennst ihn schon, da ja auch Quasi-Schweizer; aber der Vollständigkeitshalber der Hinweis auf den Blog von Damien Bowden: https://damienbod.com/ - ist voll von Auth Zeug zu OpenId, OAuth und den verschiedenen Flows.

Peter Bucher Themenstarter:in
5.941 Beiträge seit 2005
vor 3 Jahren

Hallo Abt

Ja schon gehört. Ist mir aber alles nicht wirklich hilfreich, um ehrlich zu sein.
Folgend ist mein aktueller Code der Startup.cs. Ich habe ihn dem Projekt Template von VS angepasst. So wie ich das verstehe, soll das jetzt Code Auth Flow sein.

Es kommt aber immer noch die genau gleiche Meldung, dass er id_token, etc... für implicit aktiviert haben will.
Und in "AuthorizationCodeReceived" springt er auch nicht.
Wieso ist denn das so?

Der Fehler der immer noch kommt, ist: https://login.microsoftonline.com/error?code=700054


        public void Configuration(IAppBuilder app)
        {
            string clientId = WebConfigurationManager.AppSettings["ClientId"];
            string authority = "https://login.microsoftonline.com/" + WebConfigurationManager.AppSettings["Tenant"] + "/v2.0";
            string appKey = WebConfigurationManager.AppSettings["ClientSecret"];

            app.SetDefaultSignInAsAuthenticationType(CookieAuthenticationDefaults.AuthenticationType);

            app.UseCookieAuthentication(new CookieAuthenticationOptions());
            app.UseOpenIdConnectAuthentication(
                new OpenIdConnectAuthenticationOptions
                {
                    // Sets the ClientId, authority, RedirectUri as obtained from web.config
                    ClientId = clientId,
                    Authority = authority,
                    RedirectUri = WebConfigurationManager.AppSettings["RedirectUri"],
                    // PostLogoutRedirectUri is the page that users will be redirected to after sign-out. In this case, it is using the home page
                    PostLogoutRedirectUri = WebConfigurationManager.AppSettings["RedirectUri"],
                    //Scope = OpenIdConnectScope.OpenIdProfile,
                    // ResponseType is set to request the id_token - which contains basic information about the signed-in user
                    //ResponseType = OpenIdConnectResponseType.IdToken,
                    // ValidateIssuer set to false to allow personal and work accounts from any organization to sign in to your application
                    // To only allow users from a single organizations, set ValidateIssuer to true and 'tenant' setting in web.config to the tenant name
                    // To allow users from only a list of specific organizations, set ValidateIssuer to true and use ValidIssuers parameter
                    TokenValidationParameters = new TokenValidationParameters()
                    {
                        ValidateIssuer = false // Simplification (see note below)
                    },
                    // OpenIdConnectAuthenticationNotifications configures OWIN to send notification of failed authentications to OnAuthenticationFailed method
                    Notifications = new OpenIdConnectAuthenticationNotifications
                    {
                        AuthenticationFailed = OnAuthenticationFailed,
                        // If there is a code in the OpenID Connect response, redeem it for an access token and refresh token, and store those away.
                        AuthorizationCodeReceived = (context) =>
                        {
                            var code = context.Code;
                            ClientCredential credential = new ClientCredential(clientId, appKey);
                            string signedInUserID = context.AuthenticationTicket.Identity.FindFirst(ClaimTypes.NameIdentifier).Value;
                            AuthenticationContext authContext = new AuthenticationContext(authority, null);
                            AuthenticationResult result = authContext.AcquireTokenByAuthorizationCodeAsync(
                                code, new Uri(HttpContext.Current.Request.Url.GetLeftPart(UriPartial.Path)), credential, graphResourceId).Result;

                            return Task.FromResult(0);
                        }
                    }
                }
            );
        }

        private Task OnAuthenticationFailed(AuthenticationFailedNotification<OpenIdConnectMessage, OpenIdConnectAuthenticationOptions> arg)
        {
            throw new NotImplementedException();
        }

Grüsse

--
Microsoft MVP - Visual Developer ASP / ASP.NET, Switzerland 2007 - 2011

16.807 Beiträge seit 2008
vor 3 Jahren

Es kommt aber immer noch die genau gleiche Meldung, dass er id_token, etc... für implicit aktiviert haben will.

Riecht danach, dass Du eben nicht den Auth Code Flow oder den Hybrid Flow verwendest.

Und in "AuthorizationCodeReceived" springt er auch nicht.

Weil Du durch den Fehler ja kein Code bekommst.

Du kannst auch alles erst mal mit Hilfe von Postman versuchen hin zu bekommen, damit Du Dir sicher sein kannst, dass das AAD richtig konfiguriert ist - und Du gegen die richtigen Endpunkte arbeitest.

Ich weiß leider nicht, woher Du Deine entsprechende Config genommen hast und auch kenn ich die Templates nicht.
Auch ist die URL - glaube ich - untypisch; ich kenne sie ans ../tenant/oauth2/v2.0 und nicht ../tenant/v2.0 - sind das evtl. noch alte ADAL statt MSAL Endpunkte?
Anscheinend werden hier (Use OpenID Connect to sign in users to Microsoft identity platform (formerly Azure Active Directory for developers) and execute Microsoft Graph operations using incremental consent) auch Deine URLs verwendet....

Aktuelle Azure Samples sind zB hier, falls es Dir weiter hilft:
Chapter - Enable your Web app to sign-in users using the Microsoft Identity Platform

P
441 Beiträge seit 2014
vor 3 Jahren

Ohne das jemals mit ASP.NET gemacht zu haben, einfach mal frei heraus mit meinem Halbwissen 😃.

In deinen Settings ist der ResponseType nicht gesetzt. Würdest du den auf "code" bzw auf OpenIdConnectResponseType.Code setzt, sollte das AAD mit der passenden Antwort um die Ecke kommen.

Peter Bucher Themenstarter:in
5.941 Beiträge seit 2005
vor 3 Jahren

Du kannst auch alles erst mal mit Hilfe von Postman versuchen hin zu bekommen, damit Du Dir sicher sein kannst, dass das AAD richtig konfiguriert ist - und Du gegen die richtigen Endpunkte arbeitest.

Keinen Plan was genau du damit meinst. Ich muss wohl nicht händisch Requests prüfen?
Code brauche ich ja nicht mehr als in etwa dem bestehenden Umfang. Schon verwirrend, diese Sache.

Aktuelle Azure Samples sind zB hier, falls es Dir weiter hilft:

>

Woher hast du diese Url? Scheint für ASP.NET Core zu sein; sollte ja trotzdem anwendbar sein. Nur ist es wieder mal mit IMPLICIT GRANT. Das hatte ich ja schon am laufen, möchte ich aber nicht.
Die Beispiele bringen mich nicht weiter. Ich verstehe immer nur weniger.

Mal schauen, ob ich mit dem Tipp vom Papst 😉 weiterkomme...

--
Microsoft MVP - Visual Developer ASP / ASP.NET, Switzerland 2007 - 2011

Peter Bucher Themenstarter:in
5.941 Beiträge seit 2005
vor 3 Jahren

Hallo Papst, Abt

Wenn ich auf .Code setze, springt er in die Authorisierungsmethode rein; Er kommt schon weiter und fragt nach Berechtigung des Profiles. Es ist dann aber context.AuthenticationTicket null.

--
Microsoft MVP - Visual Developer ASP / ASP.NET, Switzerland 2007 - 2011

16.807 Beiträge seit 2008
vor 3 Jahren

An welcher Stelle ist das null? Kann ich an Deinem Beitrag nicht erkennen.

Peter Bucher Themenstarter:in
5.941 Beiträge seit 2005
vor 3 Jahren

Hi Abt

Im Code ein paar Beiträge weiter oben ist - wie beschrieben - bei:


string signedInUserID = context.AuthenticationTicket

...AuthenticationTicket null.

Was ist denn das für eine Url, die du mir geschrieben hast?
Das verwirrrt mich mehr, als das es mir hilft, um ehrlich zu sein.
Auch deine gezeigten Beispiele sind für ASP.NET Core und die genutzte Bibliothek scheint nur für ASP.NET Core zu sein?

Ich habe bei Azure gesehen, dass man eine Testapplikation generieren lassen kann.
Wäre ja alles schön un gut, nur geht das nur mit IMPCIT GRANT. Da frage ich mich schon, ob das CodeFlow überhaupt geht und warum es dafür keine Beispiele gibt? Ist nicht Microsoft typisch. Weisst du da mehr?

Siehe Bild.

--
Microsoft MVP - Visual Developer ASP / ASP.NET, Switzerland 2007 - 2011

P
441 Beiträge seit 2014
vor 3 Jahren

Prinzipiell geht das mit Code Flow und AAD - ich nutze das, allerdings mit ASP.NET Core.

Sorry, der Beitrag hilft nicht viel, aber mit der "alten" Web Welt kenne ich mich kaum aus

Peter Bucher Themenstarter:in
5.941 Beiträge seit 2005
vor 3 Jahren

Hi Papst

Danke für deine Info.
Woher hast du die Vorlage genommen für ASP.NET Core für den CodeFlow?
Nutzt du eben dieses Identity.Web Dings, das ganz neue, dass in Abts neustem Link mit Beispielen auch genutzt wird?

Klar komme ich da keinen Meter weiter.

@Abt
Dir war schon bewusst, dass es hier um ASP.NET MVC (NICHT Core) geht?
Ich frage mich jetzt einfach mal, ob das überhaupt geht.... hast du - oder hat jemand ein Beispiel dafür? Muss es doch geben. Kann man sich doch nicht aus den Fingern saugen.

--
Microsoft MVP - Visual Developer ASP / ASP.NET, Switzerland 2007 - 2011

P
441 Beiträge seit 2014
vor 3 Jahren

Ich verwende die Assembly Microsoft.AspNetCore.Authentication.OpenIdConnection in Version 3.1.0


            services
                .AddAuthentication()
                .AddOpenIdConnect(configure =>
                {
                    configure.RequireHttpsMetadata = true;
                    configure.CallbackPath = "/signin-oidc";
                    configure.Authority = "https://login.microsoft.com/"+ Configuration.GetValue<string>("OIDC:AAD:Authority");
                    configure.ClientId = Configuration.GetValue<string>("OIDC:AAD:ClientId");
                    configure.ClientSecret = Configuration.GetValue<string>("OIDC:AAD:Secret");
                    configure.ResponseType = "code";
                })

16.807 Beiträge seit 2008
vor 3 Jahren

Dir war schon bewusst, dass es hier um ASP.NET MVC (NICHT Core) geht?

Ja, denn OpenId als Protokoll ist es egal, was Du für ein Framework verwendest.

Aber ich habe leider kein konkretes Beispiel für MVC mehr; weiß auch nicht, ob die überhaupt noch zur Verfügung gestellt werden.
Meine Links hatten die Intention, dass Du Dir anschaust, wie es in Core funktioniert, weil rein vom Flow muss es für die alte Welt genauso funktionieren.

OpenId und OAuth2 ist es völlig egal, ob Du ASP.NET, NodeJS oder nur gar alles händisch selbst programmierst.

Peter Bucher Themenstarter:in
5.941 Beiträge seit 2005
vor 3 Jahren

Hallo Abt

Ja... das ist mir wirklich klar. Nur habe ich keine Zeit, das komplett selber zu entwickeln und auf das läuft es hinaus, falls es da keine Beispiele gibt.
In ASP.NET Core ist alles gekapselt, ganz anders. Wie soll mir das was bringen?

Jemand eine Idee?

--
Microsoft MVP - Visual Developer ASP / ASP.NET, Switzerland 2007 - 2011

Peter Bucher Themenstarter:in
5.941 Beiträge seit 2005
vor 3 Jahren

Hallo zusammen

Implicit Flow funktioniert. Wie ist es denn da bezüglich Security?
Es sei nicht für serverseitige Anwendungen gedacht, etc.

Für Policies / Claims in ASP.NET MVC (.NET Framework) könnte das hier nützlich sein:

--
Microsoft MVP - Visual Developer ASP / ASP.NET, Switzerland 2007 - 2011

16.807 Beiträge seit 2008
vor 3 Jahren

Der Implicit Flow war mal gedacht um Ausnahmen wie Client Side Apps zu unterstützen, die andere Flows wegen fehlendem Browser Support (damals vor allem Same Origin Problematik von Scripts) nicht nutzen konnten.
Er war aber nie gedacht für Server-Side Apps.

Da es diese Problematiken mit den aktuellen Browsern aber alle nicht mehr gibt (man kann ja nun zB via CORS und anderen Header entsprechende Origin Enable-Lists führen) und der Implicit Flow nen paar Schwächen hat, gilt er als deprecated und sollte nicht mehr verwendet werden.

Der Nachfolgeflow ist u.a. inkl. besserer Sicherheit und paar mehr Features der Authorization Code Flow.