【第二弾】OAuth 2.0 + OpenID Connect のフルスクラッチ実装者が知見を語る

はじめに 本記事は「OAuth 2.0 + OpenID Connect のフルスクラッチ実装者が知見を語る」の続編となります。保護リソースエンドポイント (protected resource endpoint)、いわゆる世の中でいうところの (狭義の) Web API の実装に関する話題がメインとなります。 1. もう一つの認可 1.1. アカウント属性文脈での認可 混乱を避けるため前記事では敢えて言及しませんでしたが、認可という言葉は別の文脈で使われることがあります。その文脈では、「誰が何の権限を持っているか (who has what permissions)」という情報を扱うために認可という言葉を使います。これは、OAuth の文脈での認可「誰が誰に何の権限を与えるか (who grants what permissions to whom)」とは異なります。厄介なことに、このど

[masatotoro]

“Shiro”が参考になるらしい

[zaki-hmkc]

トークンの文字種はRFC6750にも依存するっぽい

[hirokikodama]

“RFC 7662 をサポートする認可サーバーは、イントロスペクションエンドポイント (Introspection Endpoint) を実装します。このエンドポイントに token パラメーター (必須) と token_type_hint パラメーター (オプショナル) を付けて HTTP PO

[Dai_Kamijo]

【第二弾】OAuth 2.0 + OpenID Connect のフルスクラッチ実装者が知見を語る by @darutk on @Qiita — 上條　大 (@Dai_Kamijo) August 3, 2017 from Twitter https://twitter.com/Dai_Kamijo August 03, 2017 at 03:56PM via IFTTT

[gologo13]

Oauth2とユーザ管理文脈での認可の違い、apache shiro の良さ、role = permission の集合

[nekoruri]

続編来てた