これらのクレームはあくまで標準として定義されているものであり、発行元によってはこれらに加えて独自のクレームが含まれることになります。例えばCognitoでは、トークン用途を表す token_useといった独自のクレームが含まれます。 また、JWTで使用する形式には、JSON Web Signature（以下JWS）とJSON Web Encryption（以下JWE）の2種類があります。JWSはRFC7515、JWEはRFC7516でそれぞれ定義されています。簡単な特徴としては、JWSでは電子署名がされる、JWEでは暗号化されるといった点が挙げられます。これらは組み合わせることも可能であり、IDトークンではJWSによる電子署名は必須となっているため、JWSについては必ず使用されることになります。 これらの仕様により、IDトークンではクレームを参照することでユーザー情報を確認でき、また電子署

みなさんは ID Token と Access Token の違いを理解していますか？ Access Token を使用した保護された Web API を実装する機会は何回かありましたが、理解して使っていたかというとそうではありませんでした。プライベートな Web API にアクセスするときは、Access Token を Authorization ヘッダーに Bearer で渡せばいいんでしょ? ID Token?? の認識で、なんとなく使っていたような状態でした。最近、認証・認可や OAuth 2.0 / OpenID Connect を勉強する機会があり、2 つのトークンの違いについてざっくりと理解できましたので、ブログにしてみました。 このブログでは、OAuth 2.0 / OpenID Connect に対応している Auth0 という IDaaS を使って、この 2 つのトー

をdeeplに突っ込んだもの 後で、綺麗に整形できたらする authorization　認可 authenticated. 認証 "このAPIコールを保護するためにトークンを使用しましょう。IDトークンとアクセストークンのどちらを使うべきですか？🤔 IDトークンの方がよさそうですね。結局のところ、ユーザーが誰なのか分かれば、より良い認可の判断ができるでしょ？" 同じような議論をしたことがありますか？直感で選んだ方が良さそうですが、直感的に見えることが必ずしも正しいとは限りません。IDトークンやアクセストークンの場合、明確な目的があるので、それに基づいて使うべきでしょう。間違ったトークンを使うと、ソリューションが安全でなくなる可能性があります。 "結局、何が変わるの？ただのトークンです。好きなように使えばいい。最悪何が起こるかわかりませんよ？" この2種類のトークンを詳しく見て、認証と認可

ID 連携フローの説明 1 ウェブブラウザを使い、ウェブサービスのログインページにアクセスします。 2 ウェブサービスはログインページを生成し、ウェブブラウザに返します。ウェブサービスが外部のアイデンティティプロバイダ（IdP）との ID 連携をサポートしていれば、ログインページ内に ID 連携を開始するためのリンクが埋め込まれます。 3 ID 連携を開始するためのリンクをクリックします。 4 ID 連携開始の要望を受けたウェブサービスは、対象となる IdP への認証リクエスト（OpenID Connect Core 1.0 Section 3.1.2.1. Authentication Request）を作成します。 認証リクエストの形式は、リクエストパラメーター群を含めた、IdP の認可エンドポイント（RFC 6749 Section 3.1. Authorization Endpoi

社内向け勉強会で発表した内容です。 30分でと書いてありますが、実際には50分かかりました。 また時間の関係で結構省いたりしている箇所があります。 2020/07/19追記 ご指摘をいただいた箇所を多々修正いたしました。 特にOIDCとSPAの章が初版とは大幅に変更されていますのでご注意く…

OpenID Connect概要 OpenID Connectをひと言で説明すると、 OAuth 2.0 ＋ Identity Layer ＝ OpenID Connect という表現が最もふさわしい。 OpenID Connectは、「OAuth 2.0を使ってID連携をする際に、OAuth 2.0では標準化されていない機能で、かつID連携には共通して必要となる機能を標準化した」OAuth 2.0の拡張仕様の一つである。 OpenID Connect登場以前は、OAuth 1.0／2.0ベースのID連携の仕組みがTwitterやFacebookなどの巨大SNSから提供され、人気を博した。これらの仕組みは今でも広く利用されている。 一方で、OpenID Connectの1つ前のバージョンのOpenID 2.0では、ID情報の連携はできるもののAPI連携には利用できないなど、デベロッパーに強

※この記事は別アカウント(hyiromori)から引っ越しました はじめに 最近、個人的に認証認可周りを学習していて、今回は OpenID Connect について学習したのでその内容をまとめた記事です。 世の中には既に OpenID Connect に関する優れた書籍やブログ記事が沢山ありますが、自分が学習する過程で色々なものを読むことでより理解が深まったと思うので、自分も学習したものをアウトプットすることで同じように学習している人の理解の助けになればと思い書きました。 まだ私も学習中なので、もし間違ったところなどあればコメント頂けるとありがたいです。 OpenID Connect とはなにか？ OAuth2.0をベースにして（認可だけでなく）認証も行えるようにした拡張仕様です。 なぜOAuth2.0が認証に使えないかというと、以下のように認証に使ってしまうとリスクが非常に高いからです。

はじめに 過去三年間、技術者ではない方々に OAuth（オーオース）の説明を繰り返してきました※1,※2。その結果、OAuth をかなり分かりやすく説明することができるようになりました。この記事では、その説明手順をご紹介します。 ※1：Authlete 社の創業者として資金調達のため投資家巡りをしていました（TechCrunch Japan：『APIエコノミー立ち上がりのカギ、OAuth技術のAUTHLETEが500 Startups Japanらから1.4億円を調達』）。Authlete アカウント登録はこちら！ ※2：そして２回目の資金調達！→『AUTHLETE　凸版・NTTドコモベンチャーズ・MTIからプレシリーズA資金調達』(2018 年 2 月 15 日発表) 説明手順 （１）ユーザーのデータがあります。 （２）ユーザーのデータを管理するサーバーがあります。これを『リソースサーバ

こんな話を聞いた。 ビジネスマンが、男に尋ねる。 「本は読むかい？」 「まぁ、多少は」男が答える。 「どういうのを読む？」 「小説ですかね、主にSFとか」 ビジネスマンは自分の仕事に誇りを持っている。 今、世界の経済に自分は最先端の場所で関わっていることを。 それこそがビジネスマンのアイデンティティであり、全てであった。 「小説って、それを読んで何になるの？」 「何になるって、どういう意味？」男は訊ねる。 「いや、だって小説って作り話でしょ？　この世にない架空の話でしょ？　それって今の世の中を動かすものではないよね？」 ビジネスマンは悪意をもって質問しているわけではなさそうで、真顔でそう言った。 男が返答に困っていると、ビジネスマンはこう続けた。 「俺は自己啓発系か、ビジネス書しか読まないよ。それが今生きている者には一番必要だから」 男は少し考えてこう返した。 「作り話（フィクション）が何

50代のルー大柴さんは若い世代に受けて再ブレイク。始めたブログには女性を中心にルー語でコメントが寄せられることも。この先、ルー大柴はどこへ行く？（全4回中の3回）。 若い女性にウケた最新の「ルー語」を紹介！ 売れて「いい加減になっていた」と気づいた50代 ── 34歳でブレイク後、40代は低迷期を過ごしたルーさん。50歳を過ぎて新しいマネージャーと出会い、本気で変わろうと決意。どんなふうに意識が変わりました？ ルーさん：以前は、ちょっとタカビー（高飛車）なところもあって、仕事に対しても少しルーズだったんですよね、ルーズ大柴（笑）。それを前向きな姿勢にしなきゃと。 あんなに「売れたい」と願って売れて、もっとやるべきことがいっぱいあったはずなのに、いい加減になっちゃって、だんだん落ちてきたんじゃないかな。もっと人間的な幅を広げたり、新しいスキルを学んで、表現していかないといけなかったのに。 ─

We introduce Voyager, the first LLM-powered embodied lifelong learning agent in Minecraft that continuously explores the world, acquires diverse skills, and makes novel discoveries without human intervention. Voyager consists of three key components: 1) an automatic curriculum that maximizes exploration, 2) an ever-growing skill library of executable code for storing and retrieving complex behavio

PEDRO、新体制で奏でる“生活が続いていく素晴らしさ”　3人で語り合う再スタートの経緯＆アユニ・Dが一番綴りたかったこと 「BiSH、PEDROをやって、生きていることの素晴らしさに気づいた」（アユニ） ――では、曲についても聞ければと思うのですが、「飛んでゆけ」に関してはどういう着想から作り始めた曲なんでしょうか。 アユニ：今までだと、自分が何を表現したいかとか、表現者として何を音楽にしたいのかっていうのがあまりわからなくて。考えれば考えるほどわからない状態だったんですけど、それは暮らしとか生活をおざなりにしてた部分があったので、なかなかインプットできていなかったからでもあって。BiSHをやって、PEDROをやって、生きていることの素晴らしさに気づきはじめて、暮らしってすごく美しいなって思うようになったんです。毎日続いていくものこそが生活だし、生活は切っても切れないものだなっていう気づ

CORSとは？ CORSとは、オリジン間リソース共有（Cross-Origin Resource Sharing）の略称で、異なるオリジン間でデータや画像、およびスクリプトファイルなどを共有する仕組みです。なお、CORSはオリジン（Origin）単位でコントロールします。このオリジンはURLやドメイン名と混合しやすいため、間違えて解説などに使われているケースがありますが、正しくは以下の通りとなります。 URL scheme://host:port/path/file Origin scheme://host:port URLはリソースの位置を表すため、該当ファイルのパス名までを含みますが、オリジンは通信ルールおよびホスト名（インターネット上に公開している場合はドメイン名）とポート番号までの組み合わせを単位とします。 また、CORSでは基本的に同一のオリジンか、そうでないかの差異によってコン

meta要素に http-equiv="content-security-policy" を追加すると、コンテンツセキュリティポリシー（CSP）を指定することができます。 この指定により、文書に読み込まれる各種リソースに対して制限をかけられるようになります。（他に、ナビゲーションに関連する制限なども行うことができます） CSPは、このページで説明するmeta要素の他に、Content-Security-Policy HTTPヘッダーでも指定することができます。 <meta http-equiv="content-security-policy" content="default-src 'self'">

1. はじめに以下の HTTP Response Headers に関するメモです。 COEP (Cross Origin Embedder Policy)COOP (Cross Origin Opener Policy)CORP (Cross Origin Resource Policy)CORS (Cross Origin Resource Sharing)どれもセキュリティに関連しています。 2. ポイント一覧表