はじめに 某プログラミングスクールで二年間講師をしてました。 受講生の方からの評価点は平均より高く、最終的には全インストラクターの中から代表に選ばれる立場にまでなりました。 始めた経緯 もともと、プログラミングスクールをいつか開きたいと思っていたこともあり、業務委託契約で経験が積めそうなところに応募。 即採用していただき、正社員で働く傍、副業としてプログラミング講師に。 エンジニア歴は当時は5年 得意な言語はPHPのみでした。 コロナ禍で全てが変わった 特定を避ける為に細かな時期は記述しませんが、この復業を始めてから今も尚世界を苦しめているウイルスの流行で事が大きく変貌していきました。 というのも、私が請け負っていたプログラミングスクールでは生徒様が作成したいと言う物をベースにプログラミングを教えるスクールでした。 その中で、コロナ禍前までの生徒様達は明確に、 「ECサイトが作りたい」 「

こんにちは、Qiita運営スタッフです。 今日は、Qiitaトップページのアップデートをクローズドベータ版として公開したことをお知らせします。 アップデートの目的・背景トップページは発見や繋がりを生むことができる場所としてQiitaで重要な役割を担っていますが、現在のトップページは、2017年のアップデートからUIが変わっていません。 現在のトップページのあり方を抜本的に見直し、今まで以上に発見や繋がりを生むことができる場所として、トップページの改善を行っていきたいと考えています。 まずはベータ版として公開し、ユーザーの皆様からのフィードバックを通してUIの改善を行っていきます。 新しいUIについて新しいUIの全体イメージは、以下のようになっています。 今回のベータ版では、多くのユーザーが利用する「記事に関連するページ」のみのアップデートを行なっています。その他のページに関しては、順次アッ

こんにちは、エンジニアの稲垣です。 はじめに この記事はこちらの続きです。 今回は前回Auth0に設定した情報をもとに認証のGoのクライアントを実装してみます。 なお、OpenID Connectの仕様は深掘りせずに、ユーザ認証の雰囲気を掴むことを目的としています。 それでは、見てみましょう。 認証フローについておさらい あらためて、認証フローについて確認します。 ユーザのログインボタンクリックなどをトリガーにアプリケーションサーバにリクエストが送信されます。 アプリケーションサーバはリクエストを受信すると、クライアント識別子（Client ID / Client Secretなど）を含めたリクエストを生成し、OPにリダイレクトします。 OPはリクエスト情報を検証し、認証・認可画面を表示します。 ユーザは認証に必要な情報を入力し、OPはその情報を検証します。OPは認可コードを付与し、アプリ

はじめに OAuth や OpenID Connect に関連する仕様を紹介していこうと思います。 仕様はたくさんあるものの、ほとんどオプショナルです。しかし、「認可サーバーを実装する際は、RFC 6749 だけではなく、認可コード横取り攻撃への対抗策である RFC 7636 も実装すべきである」* という点は強調しておきたいと思います。 * 「PKCE: 認可コード横取り攻撃対策のために OAuth サーバーとクライアントが実装すべきこと」という記事もご参照ください。 1. OAuth 2.0 (RFC 6749) OAuth 2.0 の仕様の本体は RFC 6749 (The OAuth 2.0 Authorization Framework) です。RFC 6749 の解説記事は世の中にたくさんあるので、ここでは要点だけ手短に紹介します。 RFC 6749 は、アクセストークンを発行