認証認可APIについて

APIの位置づけ

認証認可 とは？

  • 認証（Authentication）とは 「誰であるか」を本人確認すること。
  • 認可（Authorization）とは 「何の権限を持っているか」を確認、実証すること。

    • 【参考】https://blog.fujimisakari.com/api-authentication/

    さまざまな認証方式

    Basic（RFC 2617）

    仕組み：ユーザ名とパスワードをBase64方式でエンコードして送る

    簡易的な認証として、開発環境など内部システム認証によく使われている

    欠点

    【引用画像】https://medium-company.com/http認証方法の種類と違い/#Basic

    📝盗聴リスクがある

    Digest（RFC 2617）

    仕組み： サーバーとクライアントで共有シークレット（パスワード）を知っていることが前提の方式 クライアントでユーザー名、パスワード、ランダムな文字列をMD5でハッシュ化し、サーバーに送信する サーバー側でもハッシュ値を計算し、 クライアントから送信されたハッシュ値と合致するかを検証する

    欠点

    MD5ハッシュの欠点

  • IPAが2008年7月に発表した調査結果で、解析することが可能な古いハッシュアルゴリズムであることが書かれていた(https://www.ipa.go.jp/files/000013897.pdf)

    • 📝古い手法なので、セキュリティ面で用いるのはあまりよくないらしい

    OAuth1.0（RFC 5849）

    OAuthは、2007年に標準化されたユーザの同意のもと任意のサービスへ認可情報を移譲する仕様。クライアント（サードパーティAPP）へのアクセストークン付与可否をユーザに確認する仕組みで、認可する過程で認証処理が含まれてるので、OAuthを認証と扱っているケースは多数見受けられる。

    ※ RFC 5849で定められていますが、この仕様はOAuth2.0（RFC 6749）の策定をもって廃止されました。

    📝スマホ等の端末用に作られていなかった

    OAuth2.0（RFC 6749）

    OAuth2.0は、OAuth1.0の脆弱性の対策を施して2012年に改定されたもの

    Authorization Code Flow

    信頼(confidential)できるクライアントタイプ

    Implicit Flow

    公的(public)なクライアントタイプ

    ← 戻る