はてなブックマーク

Basic認証、Digest認証、Bearer認証、OAuth認証方式はRFCで標準化されている認証方式の中で最もよく目にする方式だろう。 Basic認証とDigest認証は多くのサーバ、クライントで実装されており導入障壁が低い認証方式だ。 機密性の高いデータを扱うサービスでは比較的安全なBearer認証、OAuth認証方式を目にすることが多い。 ここではBasic認証、Digest認証、Bearer認証、OAuth認証方式について簡単に触れる。 この4つの概要を理解しておけば大体のWebサービスは理解できるだろう。 もしサービスが固有の認証方式を実装していた場合でもこれらの方式との類似性に着目すればすぐに理解できるはずだ。SAMLやOpenIDと言ったより複雑な認証方式を理解する上でも助けになると考える。 1. Basic認証方式 最も理解しやすいのがBasic認証方式だ。RFC 261

Dockerを使ったことがある人ならこんなことを経験したことがあるかもしれない。 このように実行するとコンテナがすぐに終了してまう。 docker run ubuntu:latest このように「-it」を付けて実行するとコンテナは終了しない。 docker run -it ubuntu:latest そしてそれ以降、おまじないように「-it」をつけていないだろうか？ しかし「-it」がなくてもすぐに終了しないコンテナもある。 今回はコンテナをすぐに終了させないために「-it」がなぜ有効なのか、なぜ「-it」が不要なコンテナもあるのか整理しよう。 コンテナが終了する条件 仮想マシンはOSを実行することが目的だ。よってOSがShutdownされると仮想マシンも停止する。 コンテナはプロセスを実行することを目的だ。よってRoot Processと呼ばれるプロセスが終了するとコンテナも終了する。

Web API認証の混沌 混沌を整理する 認証とはなにか 1. 標準化されたHTTP認証方式 2. APIキー認証 3. Form認証、アクセストークン認証 Web API認証の混沌 認証に成功しないとWeb APIを叩くことはできない。まずは認証である。 認証方法がWebサービスによって異なるというのはよくある話だ。Web APIの認証方式には標準化された様々な認証方式に加えて、実に多様なサービス固有の認証方式が存在する。 よってあるサービスを利用するにはまずそのサービスが提供している認証方式を理解する必要があるがこれがWeb API初心者にとって最初の関門となる。ここで躓いてPostmanをそっと閉じた人も少なくないだろう。 混沌を整理する 認証方式を以下の3パターンに分けてみよう。 標準化されたHTTP認証方式 APIキー認証 Form認証 / アクセストークン認証 まずはこれから取