常連

OpenIdで利用するIDトークンにはJWTのexp項目として有効期限が設定されているかと思うのですが、この有効期限は設定することでどういったメリットが得られるのでしょうか？
無かった場合に、どういった問題が発生しうるか等の実際の事例も含め、具体的に教えて頂けると幸いです。
自分が調べた限りだと、「JWTが漏洩した際の悪用を防げる」という曖昧な回答がほとんどだったのですが、自分の考えでは特に悪用を防ぐ効力は無いと考えています。
理由としては、そもそもこの有効期限を検証することは任意であって、実際には有効期限が切れていた場合でも中の値（ユーザー識別子等）の情報を取り出し、利用（悪用）することは可能なためです。

ご回答の程よろしくお願いいたします。

OpenIdにおけるIDトークン(JWT)の有効期限の存在価値

Twitterを用いたサインイン処理を実装したいです、認証基盤はAws Cognitoを採用しています。

まず、調査して下記のことがわかっています。

- TwitterはOAuthのみ提供しておりOpenIDConnectを提供していない
- そのため認可のみ可能なのでIDトークンを取得できない（アクセストークンのみ取得可能）

この場合、OpenIDを提供していないのでパッと見立ててでは認証をTwitterで行うことはできないと考えています。
Cognitoで、OpenIDConnect非対応のプロバイダーを用いてサインイン（SSO）の仕組みを実現することは可能でしょうか。

TwitterでCognitoの認証を行うことは可能でしょうか

### 質問内容

OpenID Connectの「IDトークン」について、発行方法や検証方法は調べて分かったのですが、利用方法が分からないため、これについてお伺いしたいです。

### 調査した事

#### 3つのエンドポイント
3つのエンドポイントが存在し、それぞれ以下の役割をしています。
（インプリシットフローなどいくつか認証フローがありますが、ここでは以下のみ説明します。）
- 【認可エンドポイント】：RPから認証リクエストを受け、認可コードを返却する
- 【トークンエンドポイント】：RPから認可コード＆属性情報を受け、IDトークン＆アクセストークンを返却する
- 【ユーザ情報エンドポイント】：RPからユーザ情報取得リクエストを受け、ユーザ情報を返却する


#### IDトークンの検証

3つのエンドポイントから取得した情報により、RPサーバには以下の情報が存在します。
- IDトークン
- アクセストークン
- ユーザ情報

このうち「IDトークン」についてはRPサーバ側で検証をする必要があります。
（検証方法については今回関係ないので割愛します）

#### いざログイン

例えば、AさんがGoogleアカウントを使ってTeratailにログインしたい場合で考えます。
1. AさんがTeratailのログイン画面から「Googleでログイン」を押下
2. Googleの認証画面が表示されるため、ID/PWを入力
3. リダイレクト画面が表示される(画面上は何も表示されない)
4. Teratailのトップ画面に遷移する

この時の動きとして、**「2で認証成功した後、TeratailにAさんのユーザ情報が返却され、Teratailは自身のDBからAさんのユーザ情報を取得し、ユーザ情報が存在すれば認証OKとする」**という動きになると推測しているのですが、合っていますでしょうか？

そうなるとIDトークンはいざログインする際には使わない事になるため、検証後に捨てる事になるかと思うのですが合っていますでしょうか？

### 参考文献
Authleteで提供されているシーケンス図
[https://www.authlete.com/resources/templates/sequence-diagrams/](https://www.authlete.com/resources/templates/sequence-diagrams/)

TakahikoKawasakiさんのQiita記事
[https://qiita.com/TakahikoKawasaki](https://qiita.com/TakahikoKawasaki)

IPAのアクセス制御についての文書
[https://www.ipa.go.jp/security/awareness/vendor/programmingv2/contents/104.html](https://www.ipa.go.jp/security/awareness/vendor/programmingv2/contents/104.html)

OpenID Connectの「IDトークン」の使い道について

node.jsを用いてopenIdを認証に用いたシステムをexpress4で作っています。
jsonwebtoken,express-jwtライブラリを用いて作っているのですが、
**jsonwebtokenのエラーハンドリング**がよく分かりません。

不正なURLとToken有効期限切れを取りたいのですが、
どのようにハンドリングすればいいのでしょうか？

node.js(jsonwebtoken)のエラーハンドリング方法がわからない

タイトルの内容についてなのですが実装では無くユーザとしての質問です。

質問内容は以下の2点です。
・ソーシャルログインで使用している技術はユーザ側でわかるのか？(OAuth or OpenID or OpenID connect)
・ワンパスワード管理は理に適っているのか？


食べログ/google/yahoo/mixi/pixiv/ニコニコ動画/twitter/facebook/ドミノピザ....etc
色々なサービスが混在しパスワードを管理するのも一苦労です。
なのでワンパスワードのみの管理で済むソーシャルログインと言うのでまとめてしまいたいと思っています。

しかし調べてみるとソーシャルログインにも大別して OAuth と OpenID の二つがあるらしい。
特徴として
OpenID は紹介状の様なもの、OAuth は認証として合鍵を渡すようなものとして使われ
同じ認証でも全く異なるものだと言う事は理解しました。

少なくともOAuthを使ったソーシャルログインはしたくないのですが、これはユーザからみてどちらの技術を使っているというのは分かるものなんでしょうか？
またワンパスワードはやってて問題ないものなんでしょうか？(サービスが簡単に終ると入れなくなるって言うのは分かるのでfacebook/twitter/google/yahooのいずれかを使おうと思っています)

ソーシャルログインで使用されている技術について(OAuth/OpenID)

###質問
railsでline認証を行っています。そこで、id_tokenからemailも取得したいのですが取得できません。以下のコードでどこが間違っているのでしょうか。また、以下のようにputsで出力してもherokuのログに出力がされません。そこもできれば教えていただけると助かります。
###コード
model/user.rb
```
require 'uri'
require 'net/http'
class User < ApplicationRecord
  # Include default devise modules. Others available are:
  # :confirmable, :lockable, :timeoutable, :trackable and :omniauthable
  devise :database_authenticatable, :registerable, :confirmable,
         :recoverable, :rememberable, :validatable, :omniauthable, omniauth_providers: [:facebook, :line]
  
  has_many :posts

  has_many :likes
  has_many :post_likes, through: :likes, source: :post

  mount_uploader :user_image, ImageUploader

  validates :username, {uniqueness: true, presence: true, length: {maximum: 15}}

  def self.find_for_oauth(auth, code)
    id_token_payload_email = User.get_access_token(code)
    unless id_token_payload_email #クライアントアプリにemail取得をユーザが許可していない場合
      return id_token_payload_email = User.dummy_email(auth)
    end
    user = User.where(uid: auth.uid, provider: auth.provider).first
    if user == nil
      user = User.new(
      uid:      auth.uid,
      provider: auth.provider,
      email:    id_token_payload_email,
      username: auth.info.name,
      password: Devise.friendly_token[0, 20]#開発者にも分からないようにランダムなパスワードが作られる。
      )
    elsif user.provider == nil #userアカウント持っていて途中からsns認証使う場合
      user = User.new(
        uid: auth.uid,
        provider: auth.provider
      )
    end
    user.skip_confirmation!
    user.save
    user
  end

  def self.get_access_token(code)
    uri = URI.parse("https://api.line.me/oauth2/v2.1/token")#アクセストークン取得。この際に、同じハッシュにid_tokenも含まれる
    request = Net::HTTP::Post.new(uri)
    request.content_type = "application/x-www-form-urlencoded"
    request.set_form_data(
      "client_id" => ENV["LINE_APP_ID"],
      "client_secret" => ENV["LINE_APP_SECRET"],
      "code" => "#{code}",
      "grant_type" => "authorization_code",
      "redirect_uri" => "https://spot-share-site.herokuapp.com//users/sign_up",
    )

    req_options = {
      use_ssl: uri.scheme == "https",
    }

    response = Net::HTTP.start(uri.hostname, uri.port, req_options) do |http|
      http.request(request)
    end
    id_token = JSON.parse(response.body)["id_token"]
    puts id_token
    id_token_payload = User.get_id_token(id_token)
    return id_token_payload[:email]
  end

  def self.get_id_token(id_token)
    uri = URI.parse("https://api.line.me/oauth2/v2.1/verify") #id_tokenの中身を取得(ペイロード部)
    request = Net::HTTP::Post.new(uri)
    request.content_type = "application/x-www-form-urlencoded"
    request.set_form_data(
      client_id: ENV["LINE_APP_ID"],
      id_token: id_token
    )

    req_options = {
      use_ssl: uri.scheme == "https",
    }

    response = Net::HTTP.start(uri.hostname, uri.port, req_options) do |http|
      http.request(request)
    end

    puts response

    return response
  end

  def self.dummy_email(auth)
    return "#{auth.uid}-#{auth.provider}@example.com"
  end

end

```
controller/users/omniauth_callbacks_controller
```
# frozen_string_literal: true

class Users::OmniauthCallbacksController < Devise::OmniauthCallbacksController
  # You should configure your model like this:
  # devise :omniauthable, omniauth_providers: [:twitter]

  # You should also create an action method in this controller like this:
  # def twitter
  # end

  # More info at:
  # https://github.com/heartcombo/devise#omniauth

  # GET|POST /resource/auth/twitter
  # def passthru
  #   super
  # end

  # GET|POST /users/auth/twitter/callback
  # def failure
  #   super
  # end

  # protected

  # The path used when OmniAuth fails
  # def after_omniauth_failure_path_for(scope)
  #   super(scope)
  # end
    def facebook
      callback_from :facebook
    end

    def line
      callback_from :line
    end
  
    private
    def callback_from(provider)
      provider = provider.to_s
      code = params[:code]
  
      @user = User.find_for_oauth(request.env['omniauth.auth'], code)
      if @user.persisted?
        flash[:notice] = I18n.t('devise.omniauth_callbacks.success', kind: provider.capitalize)
        sign_in_and_redirect @user, event: :authentication
        #sign_in(:user, @user)
      else
        session["devise.#{provider}_data"] = request.env['omniauth.auth']
        redirect_to new_user_registration_url
      end

      def failure
        redirect_to root_path
      end
    end
  

end

```
色々調べると、initializer/omniauthにてomniauthをオーバライドしてopenidconnectを実装している人が多かったです。しかし、上記のコードでemailが取得できない理由が分かりません。どうか宜しくお願い致します。

###試したこと
ログを見てみると、emailにはdummy_emailで生成されたメールアドレスが入っていたのでid_tokenのペイロード部にemailがなかったかそもそもアクセストークン取得やペイロード部取得のhttp通信がうまくいっていないか。そこで、よく見ると#<Net::HTTPBadRequest:0x0000562b9349bd48>と返ってきてました。

###参考
https://developers.line.biz/en/reference/line-login/#refresh-access-token
###環境
Ruby version 2.7.3

Rails version 6.1.4.1

sns認証にて(主にlineで)id_tokenからemail取得ができない

OpenID2.0についての質問です。
※OpenID Connectではありません。

OpenIDを利用した認証にて、
OP(OpenIDProvider)での初回認証後、そのユーザが既に認証済みということをRPはどのように判断するのでしょうか。

初回認証以降の話はOpenIDの仕様として定められていない認識です。
初回認証成功時にトークンを発行し、そのトークンをクライアント側がCookieなりlocalStorageなりに保持し、
リクエストの度にそのトークンを検証する形になるのでしょうか？
SSOを実現する（異なるRPにて）場合は、どのような実装が必要になるのかイメージが湧きませんでした。

ご教示いただけますと幸いです。