GoでのAuth0の実装（復習）
Watson-Seigo-auth0 SDK
Watson-Sei認証方式の種類
- ユーザー名/パスワード認証（Database Connections)
- ソーシャルログイン(Social Connections) - Google, Facebook, Xなど
- OpenID Connect(OIDC) - 他のOpenID Connectプロバイダとの連携
- SAML2 - エンタープライズアプリケーションとのシングルサインオン（SSO）
- 他要素認証（MFA) - SMS, EmailのOTPや、google Authenticatorなど
- パスワードレス認証(Passwordless) - マジックリンクやOTP
- エンタープライズ連携 - Active Directory、LDAP、ADFS等の連携
- カスタム認証（Custom Database Connection) - 独自のデータベースを使った認証
Watson-Sei結構前に実装した記憶だけで再度実装するのはよろしくないので、新しく学び直すということで。
Auth0でもSocialやOpenID Connectを使用して、ブランド依存な認証機能をユーザー管理サーバーを自前で用意せずに実装しようと思う。まず、認証機能がうまく動いてるかを確認する上でもクライアントコードを書いて、アクセストークンを取得する必要が出てくる。これは、公式のドキュメントを参考にしてしまえばいいかなと。その後に、アクセストークンを認証用ミドルウェアが処理をして、正しいトークンであることと、ユーザー情報のコンテキストへの格納、必要なクレーム（権限）を持っているのかを処理させる。あとは、色々なルートで使用できるように共通化関数として実装できれば良いと考えている。
Watson-SeiAuth0のログイン画面リンクの生成は以下のリンクが楽でいい（将来的には、コードベースで生成するべき）
Watson-SeiOauth2.0のログインフローの実装については、auth0 docsに明確に示されている。
Watson-Sei異なるドメインでの認可フローを使用する場合（クライアントとリソースサーバーが異なる場合）、Authorization Code Flowを使用することが推奨されている。
Watson-SeiAudience検証とは？
Audience検証は、アクセストークンが特定のAPI（リソースサーバー）へのアクセス権を持つことを確認するために必要です。Audience（audクレームとしてトークンに表示される）は、そのトークンの意図された消費者、つまりAPIを定義します。この検証により、APIはトークンが自分自身に対して有効に発行されたことを確認し、不正なアクセスを防ぐことができます
Issuer検証とは？
Issuer検証も同様に重要です。Issuer（issクレームとして表示される）は、トークンを発行した認証サーバーを指します。この検証を行うことで、トークンが信頼できる認証サーバーから発行されたものであることをAPIが確認できます。これにより、偽造されたトークンや他の認証サーバーから不正に発行されたトークンを使用したアクセスを防ぐことができます
Watson-SeiCreate Action Flowで事前登録、登録後、ログイン時などのアクションを実装することができる。
ここで、確認メール機能などをライブラリを用いてノーコードで実装することも可能らしい。
Watson-SeiClaimsに制限事項であるRolesを付与する方法。