diadia

興味があることをやってみる。自分のメモを残しておきます。

認証についての記事を見つけた

androidアプリ開発 プログラミング全般

資料

How to create an application in Kotlin and secure it using JSON Web Tokens (JWTs)

メモ

OAuthに出てくる登場人物

  1. Gmailのアカウントデータを保有しているサーバー側(この場合はgoogle)
  2. Gmailアカウント所有者
  3. Gmailのデータにアクセスする必要があるサードパーティアプリケーション
  1. A resource server: A server where the user’s data is kept. In this case, that would be Gmail because your contacts would be kept there.
  2. A user who owned the resources at Gmail; and
  3. A client: A third-party application that needed access to your data from the resource server. In other words, Linked In (the third party) that needed your Gmail (resource server) contacts.

OAuthのバージョンによる後方互換性

OAuthが出現して以来、短い間で改定が行われ、現行OAuth2が人気である。そしてOAuth2には後方互換性がない。

OAuth has, since its advent, been revised twice as v1, v1a and v2.0. Version 2.0 is the most recent and popular one, and the versions are not backward compatible.

OAuthの有用性

OAuthによってサードパーティのアプリケーションに大きなサイトのアカウント認証情報(例えば、usernameやpassword)を渡さなくても済むようになった。

so that you wouldn’t have to give your Gmail username and password to Linked In.

OAuthの有効期限

OAuthには有効期限が存在する。

as it carries an expiry timestamp and may even be encrypted using symmetric or asymmetric encryption.

認証方法を選択できる

クライアントはアクセストークンは以下の３つの方法で認証サーバーに送られる。 GETリクエストの一部分として送られる。 POSTのbodyの中身の一部として送られる。 HTTPリクエストヘッダーのいち部分として送られる。

With every subsequent request, the client sends this string back to the server in one of three ways: 1. As a part of the URL in a GET request, 2. As the part of the body in a POST request, or 3. (The preferred way) sent as part of the Authorization HTTP header in the following form

誰が認証方法を決めるのか

OAuthはリクエストでトークンを送る方法を定めず、認証サーバーにその選択を委ねている。 だから認証サーバー(例えばFacebook側のサーバー)がどの様にリクエストを送るかを定めている。 言い換えれば、JKWが使えるかどうかは承認サーバーのドキュメントを見ないといけない。 (クライアント側いわゆる、アプリケーションでOAuthを利用する側は自由にトークンによる認証リクエストメソッドをどれを使うかは自由に定められることはできない。)

The OAuth 2.0 specification pussyfoots its way out of mandating a method, deferring the choice to the authorization server.