OAuth 2.0 (RFC 6749) が定義するグラントフローのアニメーションです。各フローがどのように動作するかを、順を追って説明しています。
最も広く使われているグラントフローです。
リソースオーナー（エンドユーザー）の同意に基づいて認可サーバーから発行された「認可コード」を用いて、クライアントは認可サーバーからアクセストークンを取得します。
発行されたアクセストークン（およびリフレッシュトークン）の更新（リフレッシュ）を行うためのグラントフローです。
クライアントは、別のグラントフローの実行結果として取得済みの「リフレッシュトークン」を用いて、認可サーバーからアクセストークン（およびリフレッシュトークン）を取得します。
ユーザーが関与しないクライアント向けに定義されたグラントフローです。
リソースオーナー（エンドユーザー）ではなく、クライアントが自身のクレデンシャル（例: クライアント ID / クライアントシークレットの組、公開鍵証明書、SAML アサーション） を用いて、認可サーバーからアクセストークンを取得します。
Authlete を用いた場合の認可コードグラントフローです。
認可サーバーは、同グラントフローにおける「認可リクエスト」「トークンリクエスト」の内容を、 そのまま Authlete に「丸投げ」します。 Authlete はそのリクエストの内容に応じて処理を行い、認可サーバーに「次に何をすべきか」を回答します。 これにより、認可サーバーは OAuth 2.0 のリクエスト・レスポンス処理の実装や、 アクセストークンの管理を外部化できるようになります。
Web ブラウザー上で動作するクライアント向けに定義された（しかし現在は非推奨となっている）グラントフローです。
リソースオーナー（エンドユーザー）の同意に基づいて、認可サーバーは、そのリソースオーナーが利用する Web ブラウザー上のクライアントにアクセストークンを発行します。
ユーザー ID とパスワードに基づいて API アクセス制御を行っているサービスを、OAuth 2.0 に移行させるために定義された（しかし現在は非推奨となっている）グラントフローです。
クライアントは、リソースオーナー（エンドユーザー）から受け取った ID とパスワードを用いて、認可サーバーからアクセストークンを取得します。