OAuth

posted by 生活小白 on 3月 13, 2019 No Comments
「OAuth」 とは、サービスのユーザーが、サービス上にホストされている自分のデータへのアクセスを、自分のIDやパスワードを渡すことなく、第三者のアプリケーションに許可するためのフレームワークです。
OAuth is a framework where a user of a service can allow a third-party application to access his/her data hosted in the service without revealing his/her ID or password　to the application.

何をするためのものか

重要なのは「第三者のアプリケーションにユーザーの ID & パスワードを渡さない」という点です。これを実現するために「OAuth」があります。
例えば、自分のFacebookタイムラインを見やすく表示してくれるアプリケーションがあったとする。これを利用するには、アプリケーションに、タイムラインの取得が必要になります。
タイムライン投稿の取得を実現する一番簡単な方法は、アプリケーションにFacebookのIDとパスワードを設定することですが、Facebook以外に個人情報を渡すのはちょっと嫌なんです。
そんな時、OAuthを使ってIDとパスワードをアプリケーションに教えることなく、イムライン投稿権限を間接にもらうことになります。

認可 = 認証 ?

「OAuth」 は 認可 (authorization) の仕様であり、認証 (authentication) の仕様ではありません。
用語說明
認証 (authentication)誰であるか（Who one is.）
認可 (authorization)誰が誰に何の権限を与えるか（Who grants what permissions to whom.）
認証と認可という概念をよく混乱していますが、最も一般的な認証 (authentication)　方法は ID とパスワードの組を提示してもらうことです。ユーザが誰なのかを特定するための処理です。
一方、認可(authorization)　はユーザーがクライアントアプリケーションに権限を与えることです。
例えば、「ユーザA」が「サービスB」に「アプリC」の「タイムライン投稿権限」を求めています。

OAuth 認証

でも、一般的な認可処理には前述のように「ユーザA」の認証処理も含まれているので、認可されたことは、ユーザーが認証されたということもあります。これが「OAuth 認証」です。
だから、今アプリケーションにユーザーをログインさせる際、FacebookやTwitterなどの外部サービスのアカウント（e.g. プロフィール）を使えるようなことで、「ユーザーの ID とパスワードの管理を外部サービスに任せることができる(= 自分のサービスでやる必要がない)　という利点があります。それも「OAuth 認証」の一つ形でもあります。
http://i.stack.imgur.com/zI0Gp.png

OAuthを実装する要点

http://oauth.net/core/diagram.png
  1. アプリケーションの登録 ConsumerはService ProviderからOAuth利用許可を得ることです。具体的にはService ProviderにConsumer登録を行い、Consumer KeyとConsumer Secretという値を取得することで行います。
  2. 必要な情報へのアクセス権を認可されために、Request Tokenをリクエストする 前述のFacebook OAuth認証の例では，認可が必要な情報はFacebookタイムラインのアクセス権取得の指示はユーザがサビース上の「Facebookへ」というリンクをクリックする時、ConsumerはバックグラウンドでService Providerにアクセスし、未認可のRequest Tokenを取ることです。そして、リダイレクでその未認可のRequest TokenをURL Parameterに付着て行います。
  3. UserはService Provider上でConsumerへのアクセス権委を許可する 未認可のRequest Tokenを認可済として、Facebook上で「Grant access」を取ります。Service ProviderはUserをConsumerにリダイレクトさせる。この際Service Providerは認可済のRequest TokenをURLに含めます。
  4. ConsumerはバックグラウンドでService Providerと通信を行い，認可済のRequest Tokenを実際のアクセス権を示すAccess Tokenと交換する
  5. ConsumerはAccess Tokenを利用して，特定の情報にアクセスする Access Token取得後は、ユーザが明示的にそのAccess Tokenを無効にするか、Access Tokenにあらかじめ設定された有効期限をすぎない限り、Consumerは何度でも情報にアクセスすることができます。

Request Tokenの定義

Service Providerがアプリケーションに対して一時的に発行するもの。Userがアプリケーションを承認するプロセスでのみ利用します。
Used by the Consumer to ask the User to authorize access to the Protected Resources. The User-authorized Request Token is exchanged for an Access Token, MUST only be used once, and MUST NOT be used for any other purpose. It is RECOMMENDED that Request Tokens have a limited lifetime.
例：NAVER OAuth APIにRequest Tokenをリクエストする
GET http://nid.naver.com/naver.oauth?mode=req_req_token&
oauth_callback=http://example.com/OAuthRequestToken.do&
oauth_consumer_key=WEhGuJZWUasHg&
oauth_nonce=zSs4RFI7lakpADpSsv&
oauth_signature=wz9+ZO5OLUnTors7HlyaKat1Mo0=&
oauth_signature_method=HMAC-SHA1&
oauth_timestamp=1330442419&
oauth_version=1.0 HTTP/1.1
Accept-Encoding: gzip, deflate
Connection: Keep-Alive
Host: nid.naver.com
Parameters說明
oauth_callbackRequest Tokenを取った後のリダイレアトレス　(アトレスがない場合は("oob") に書きます)
oauth_consumer_keyService Providerがアプリケーションに対して発行するもの、アプリケーションを識別するために利用する
oauth_nonce重覆されるRequestをDuplicationしないための変数（oauth_timestampがUNIQUEの前提にとて使う）
oauth_signature認可についての暗号化情報
oauth_signature_methodoauth_signatureの暗号化手段
oauth_timestampRequest生成の時間
oauth_versionOAuthのVersion

Access Tokenの定義

Service Providerがアプリケーションに対して発行するもの。ユーザー情報にアクセスし放題になるプロセスでのみ利用します。それがあればOAuthを利用した各種APIの利用可能となります。
Used by the Consumer to access the Protected Resources on behalf of the User. Access Tokens MAY limit access to certain Protected Resources, and MAY have a limited lifetime. Service Providers SHOULD allow Users to revoke Access Tokens. Only the Access Token SHALL be used to access the Protect Resources.
Parameters說明
oauth_consumer_keyService Providerがアプリケーションに対して発行するもの、アプリケーションを識別するために利用する
oauth_nonce重覆されるRequestをDuplicationしないための変数（oauth_timestampがUNIQUEの前提にとて使う）
oauth_signature認可についての暗号化情報
oauth_signature_methodoauth_signatureの暗号化手段（HMAC-SHA1やHMAC-MD5など）
oauth_timestampRequest生成の時間
oauth_versionOAuthのVersion
oauth_verifierUserがアプリケーションを承認するため、PINコードと呼ばれたもの
oauth_tokenRequest TokenからもらうToken
例： Access TokenでOpen APIをリクエストする
POST /cafe/getMenuList.xml HTTP/1.1
Authorization: OAuth oauth_consumer_key="dpf43f3p2l4k3l03",
oauth_token="nSDFh734d00sl2jdk",
oauth_signature_method="HMACSHA1",
oauth_timestamp="1379123202",
oauth_nonce="csrrkjsd0OUhja",
oauth_signature="MdpQcU8iPGGhytrSoN%2FUDMsK2sui9I%3D"
Accept-Encoding: gzip, deflate
Connection: Keep-Alive
Host: http://openapi.naver.com
追記、Amon2での実装は　はてなサービスにおける OAuth　に参考できます。

OpenID Connect

「OAuth 認証」の普及、OpenID や SAML など認証 (authentication)の仕様群もどんどんOAuth上に乗せる形に進化しています。その認証のための新しい仕様は　OpenID Connect　と呼ばれます。
(Identity, Authentication)+ Authorization = OpenID Connect
OAuth による認可と同時に、OpenID Connect による認証もできるようになりました。
http://i.stack.imgur.com/89Wmh.png

參考資料

0 留言:

發佈留言