In a 2013 interview with a Japanese newspaper Asahi, Mr Toriyama said he had "no idea" how Dragon Ball became so popular around the world.
He described the series as a miracle, "given how it helped someone like me who has twisted, difficult personalities do a decent job and get accepted by society".
"When I was drawing the series, all I ever wanted to achieve was to please boys in Japan," he said, according to news agency AFP.
⇧ 日本の子供たちだけでなく、世界にまで影響を与えてますから、偉大過ぎましたな。
夢中になったものなぁ。
素敵な作品をありがとうございます、これからも読み継がれていくことでしょう。
eKYC（electronic Know Your Customer）とOpenID Connect
ネットの情報によると、
2018 年 11 月 30 日に『犯罪による収益の移転防止に関する法律』（犯罪収益移転防止法／犯収法）を改正する命令が公表されました。この改正で「オンラインで完結する自然人の本人特定事項の確認方法の追加」が行われ、eKYC（electronic Know Your Customer）の根拠法となりました。
Identity Assurance - eKYC 時代の OpenID Connect #openid_connect - Qiita
そして、当改正から約一年後の 2019 年 11 月 11 日、世界標準仕様策定団体である OpenID Foundation から『OpenID Connect for Identity Assurance 1.0』という技術仕様の第一版が公開されました。また、これを受けて同団体内に新たに『eKYC and Identity Assurance ワーキンググループ』が設置されました。それから約半年後の 2020 年 5 月 19 日には、同仕様の第二版が公開されました。
Identity Assurance - eKYC 時代の OpenID Connect #openid_connect - Qiita
⇧ とあり、日本の法改正によって『eKYC（electronic Know Your Customer）』が定義されたのと、OpenID Foundationという団体が『eKYC and Identity Assurance ワーキンググループ』を設置したのが結構、近い時期らしい。
どうやら、
OpenID Connect for Identity Assurance 1.0 (OIDC4IDA または IDA) は、OpenID Foundation の eKYC-IDA ワーキンググループが開発した技術仕様です。当仕様は OAuth 2.0 と OpenID Connect (OIDC) を基盤とし、自然人の検証済みクレームを格納する JSON 構造を定義します。
⇧『eKYC and Identity Assurance ワーキンググループ』は、OpenID Foundationという団体が抱えるプロジェクトの1つということらしく、『OpenID Connect for Identity Assurance 1.0 (OIDC4IDA または IDA) 』という技術仕様を開発しているらしく、その技術仕様が、
- OpenID Connect（OIDC）
- OAuth 2.0
を基盤にしていると。
ここでの『クレーム』は技術用語で、名前、誕生日、住所等のユーザー属性を意味しています。
ここでの『検証済み』とは、パスポートや運転免許証等の証拠によってクレームの真正性が検証済みであることを意味しています。
インターネット上にはユーザー登録可能なウェブサービスがたくさんあります。それらの多くは属性情報の登録をユーザーに求めますが、登録されるデータはユーザーが自己申告したものに過ぎず、法的な文脈では利用できません。ここで OIDC4IDA が登場します。
※ 本記事の英語版はこちら → "OpenID Connect for Identity Assurance, explained by an implementer"
⇧ ということらしく、説明を見る感じでは『OpenID Connect for Identity Assurance 1.0 (OIDC4IDA または IDA) 』は、法的な根拠を持たせるものになるってことなんかね？
明言していないけど...
OpenID Connectとは？
ネットの情報によると、
What is OpenID Connect
OpenID Connect is an interoperable authentication protocol based on the OAuth 2.0 framework of specifications (IETF RFC 6749 and 6750). It simplifies the way to verify the identity of users based on the authentication performed by an Authorization Server and to obtain user profile information in an interoperable and REST-like manner.
OpenID Connect enables application and website developers to launch sign-in flows and receive verifiable assertions about users across Web-based, mobile, and JavaScript clients. And the specification suite is extensible to support a range of optional features such as encryption of identity data, discovery of OpenID Providers, and session logout.
For developers, it provides a secure and verifiable answer to the question “What is the identity of the person currently using the browser or mobile app that is connected?” Best of all, it removes the responsibility of setting, storing, and managing passwords which is frequently associated with credential-based data breaches.
⇧ 上記の説明が正しいとすると、
『OpenID Connect is an interoperable authentication protocol based on the OAuth 2.0 framework of specifications (IETF RFC 6749 and 6750).』
とあるので、「OAuth 2.0」の仕様を元にしているらしいので、「OAuth 2.0」の機能の一部ってことになりそうね。
「OAuth 2.0」の機能も込みなのか、「OpenID Connect」のみの部分なのか、分からないのですが、
⇧ 登場人物としては、大きく分けて、
- Authentication
- OpenID Provider (OP) or Identity Provider (IDP)
- Client
- Identity Token
- Relying Party (RP)
- User
⇧ 6つあることになっている。
Oktaの公開しているドキュメントで、
What kind of client are you building?
The type of OAuth 2.0 flow depends on what kind of client that you're building. This flowchart can quickly help you decide which flow to use.
⇧ とあり、Clientに依存するらしい。
シーケンス図を掲載してくれているのですが、
- Authorization Code flow with PKCE（Proof Key for Code Exchange）
- Interaction Code flow
- Resource Owner Password flow
- Client Credentials flow
- SAML 2.0 Assertion flow
- Implicit flow
⇧ 6つのパターンが載っていた。
■Authorization Code flow with PKCE（Proof Key for Code Exchange）
■Interaction Code flow
■Resource Owner Password flow
■Client Credentials flow
■SAML 2.0 Assertion flow
■Implicit flow
⇧ う～む、「OpenID Connect」の部分が分からん...
OAuth 2.0
OAuth 2.0 is a standard that apps use to provide client applications with access. If you would like to grant access to your application data in a secure way, then you want to use the OAuth 2.0 protocol.
The OAuth 2.0 spec has four important roles:
- client: The application that wants to access some data.
- resource server: The API or application that stores the data the client wants to access.
- resource owner: The owner of the data on the resource server. For example, you're the owner of your Facebook profile.
- authorization server: The server that manages access and issues access tokens. In this case, Okta is the authorization server.
Other important terms:
- OAuth 2.0 grant: The authorization given (or granted) to the client by the user. Examples of grants are Authorization Code and Client Credentials. Each OAuth grant has a corresponding flow. See Choose an OAuth 2.0 flow.
- access token: The token issued by the authorization server (Okta) in exchange for the grant.
- refresh token: An optional token that is exchanged for a new access token if the access token has expired.
OpenID Connect
OpenID Connect (OIDC) is an authentication standard built on top of OAuth 2.0. It defines an ID token type to pair with OAuth 2.0 access and refresh tokens. OIDC also standardizes areas that OAuth 2.0 leaves up to choice, such as scopes, endpoint discovery, and the dynamic registration of clients. Okta is OpenID Certified .
Although OIDC extends OAuth 2.0, the OIDC specification uses slightly different terms for the roles in the flows:
- OpenID provider: The authorization server that issues the ID token. In this case Okta is the OpenID provider.
- end user: The end user's information that is contained in the ID token.
- relying party: The client application that requests the ID token from Okta.
- ID token: The token issued by the OpenID provider that contains information about the end user in the form of claims.
- claim: The claim is a piece of information about the end user.
The high-level flow looks the same for both OpenID Connect and regular OAuth 2.0 flows. The primary difference is that an OpenID Connect flow results in an ID token, in addition to any access or refresh tokens.
⇧ ドキュメントによると、
- OpenID provider
- relying party
の2つについては、明示的にOktaって記載があるから、Okta以外での実装となった場合も気にするのは、上記の2つってことで良いんかね？
う～む、認証・認可まわりってかなり重要だと思うんだけど、説明が分かり辛過ぎるんだが...
登場人物が、シーケンス図のどの部分を担当してるのかが見えて来ないんよね...
「OAuth 2.0」の登場人物と「OpenID Connect」の登場人物の関係性を、シーケンス図で説明できてないのよな...
2024年3月10日（日）追記：↓ ここから
何やら、
実際、このような流れでは仕様策定が行われていないのです。
- OAuthは利用環境や技術スタックの変化に伴い、リソースアクセスのための仕組みとして1.0 -> WRAP(2.0の初期Draft的な立ち位置) -> 2.0と進化してきた
- OpenIDも同様の変化を意識しつつ、認証イベントのやり取りのためにOpenID 2.0 -> OpenID Connect と仕様策定が進められてきた
- 同時期に存在することになったOAuth 1.0とOpenID 2.0を同時に使用するための拡張仕様が策定されたこともあるが、別路線で進んでいた
- OpenID Connectでは認証イベントのやり取り(IDTokenのあたり)に加え、UserInfo Endpointから非同期/継続的に最新のユーザー情報を取得するという要件があり、この部分が機能的にOAuthと重なる部分である
- OpenID ConnectのJSON、RESTなどを使うという設計方針と、OAuth WRAPあたりが一致していたため、別々に策定を進めるのではなく「OAuth 2.0の上にIdentityレイヤを乗せる形」として最適化を進めるべく合流した
というのが実際に行われたことです。
"OpenID Connectは認可のための仕組みであるOAuth 2.0を認証のために拡張したもの" という表現が気になったが実は... - r-weblife
⇧ということのよう。OpenIDが先に開発されていたけど、仕様に落とし込んだりをOAuth 2.0で行ったということなんかね？
機能が重なるって言うことは、
- OAuth 2.0 + OpenID Connect
- OAuth 2.0のみ
のどちらでも認証・認可が可能ってことなんかね？
⇧ ということらしい。
ザックリと、認証で利用する情報が異なるらしく、
ということみたいね。
とりあえずは、アクセストークンに加えてIDトークンも利用している場合は、「OAuth 2.0」に加えて「OpenID Connect」も利用していると考えて良さそうってことですかね？
う～む、情報が錯綜していてよく分からんですが...
2024年3月10日（日）追記：↑ ここまで
毎度モヤモヤ感が半端ない...
今回はこのへんで。
