OAuth

スコープ

認可コード

グランドタイプ

認証のために使われるケース

メリット

プロジェクトの構成要素をOAuth2.0 のロールにマッピングできるになる

利用すべきグランドタイプを判断できる

OAuth2.0の仕様を読めるようになる。

用語

サードパーティアプリ

HTTPサービス

限定的なアクセス

認可フレームワーク

権限の認可(authorization)を行うためのオープンスタンダード

登場人物の整理が難しい。

サービスのパスワードを渡さずに、他の主体（エージェント、クライアント?)に必要な権限を許可して、働いてもらう。

ユーザーのパスワードの代わりに、認可サーバはクライアントにアクセストークンを渡す。

ユーザーはクライアントにgrantを渡す。

クライアントはgrantを認可サーバーに渡す、クライアントはアクセストークンを得る。

クライアントはもらったアクセストークンでリソースのあるエンドポイントにrequestを投げる。

でもって、認可フロー、grantのもらい方？が４つある。

認可コードがgrantされた証拠とするもの　

response_type=code, grant_type=authorization_code&code={code}

認可コードなしにクライアントにアクセストークンを渡す。

response_type=token, refresh_tokenは使わない。

クライアントがpasswordを知ってる(ユーザーのパスワードを渡さないのが利点だが、、専用のパスワード？)

grant_type=password

認証済みのクライアント

...

twitterは、OAuth1.0

library(python)

新しめの python library

調べてる途中で、みつけた。