クロスドメインでのデジタルアイデンティティを守る APIアクセス権を委譲するプロトコル、 OAuthを知る 作島 立樹 NRIパシフィック 2008/1/21 マッシュアップと呼ばれる仕組みで、既存のWebサービスが次々とつながり、新たなサービスが登場している。しかし、メールアドレスなど重要な個人情報が意図せずに「つながれてしまう」可能性もある。そこで登場したのがアクセス権の「委譲」を目的としたプロトコル、OAuthである。本記事ではOAuthの仕組みとともに、なぜそれが登場したのかという背景にも触れる(編集部) マッシュアップの犠牲になるユーザーのアイデンティティ GETなどのHTTPメソッドをもちいてURLへリクエストする、いわゆる「RESTful」【注1】なWeb APIを使ったアプリケーション同士の交流は、いままさに隆盛を極めている。「マッシュアップ」と呼ばれているこのサービス形態
OAuth(オー オース[1])は、権限の認可 (authorization) を行うためのオープンスタンダードである。 2016年現在の最新の標準は、2012年にRFCとして発行されたOAuth 2.0である(RFC6749、RFC6750)。本稿でも以下、OAuth 2.0をベースに解説する。 OAuth 2.0では以下の4種類のロール(役割)を考える[2]: リソースオーナー (resource owner) リソースサーバー (resource server) クライアント (client) 認可サーバー (authorization server) リソースオーナーが人間である場合は、リソースオーナーのことをエンドユーザーともいう。 認可サーバーはリソースサーバーと同一のサーバーでも異なるサーバーでもよい[2]。 これら4つのロールを具体例に即して説明する。今、ウェブサイトA(リ
〒169-0051 東京都新宿区西早稲田2-3-26-301 info@machiken.co.jp TEL:03-5273-2587 FAX:03-5273-2582
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く