Seamlessly integrate your users’ emails, calendars, and contacts Accelerate product velocity with a single platform to connect to your users’ emails, calendars, and contacts, empowering you to build customizable email and scheduling capabilities. Build email and scheduling workflows faster with Nylas Launch critical features way ahead of schedule by spending less time on email and calendar infrast

こんばんは。ritouです。 Digital Identity技術勉強会 #iddance Advent Calendar 2020 1日めの記事です。 qiita.com 初日なのでゆるふわな話をしましょう。 何の話か もうだいぶ前ですね。9月のお話です。こんなTweetを見かけました。 社内Slackにいる「OAuth認証」と書くと訂正してくれるbotが丁寧な解説をするようになっていた 認証(Authentication)と認可(Authorization)は間違えやすいわりにミスると甚大な被害をもたらしがちなので、常日頃から意識を高めていきたいですね pic.twitter.com/oVQxBgZcHS— greenspa (@greenspa) 2020年9月28日 このbotに対する思うところはもう良いです。 今回は、「OAuthの仕様に沿ってID連携を実装するいわゆる"OAut

令和3年9月更新 マイナンバー（社会保障・税番号制度）は令和3年9月1日よりデジタル庁に移転しました。 平成28年1月4日から令和3年8月31日に掲載した情報は、国立国会図書館インターネット資料収集保存事業（WARP）ホームページにて御覧いただけます。

xID(クロスID)は、身分証、カギ、ハンコの機能を持つデジタルIDアプリです。マイナンバーカードと連携してIDを生成すると、簡単にログイン、電子署名、そして本人確認を行うことが可能になります。

血税1兆円をドブに捨てた「住基ネット」〜元祖マイナンバー、あれはいったい何だったのか？ 【怒りのレポート】 カードの普及率は、わずか20人に1人。大半の人が使い道さえ知らないまま、住基ネットがフェードアウトする。ここで責任のありかを明らかにしておかなければ、マイナンバーも同じ道をたどる。 何の役にも立たなかった 「私は'07年頃、総務省の住基ネット普及促進担当者に呼び出されたことがありました。一向に普及しない住基ネットについて、批判的な記事を書いたからです。 そこで先方が『頭ごなしに批判するのはどうかと思う』『住基ネットは国民の役に立つ』と言うので、『そんなにいい制度なら、当然あなたたちは全員、住基カードを持っているんでしょうね』と聞いたら、室長以下、その場にいた担当者が誰一人持っていなかった」 こう述懐するのは、行政とITの取材に長年携わってきた、ジャーナリストの佃均氏だ。 昨年12月2

Intro Cookie は、ブラウザに一度保存すれば、次からその値を自動的に送ってくるという、非常に都合の良い仕様から始まった。 State Less が基本だった Web にセッションの概念をもたらし、今ではこれが無ければ実現できないユースケースの方が多い。 冷静に考えればふざけてるとして思えないヘッダ名からもわかるように、当初はこのヘッダがこんなに重宝され、 Web のあり方を変えるかもしれないくらい重要な議論を巻き起こすことになるとは、最初の実装者も思ってなかっただろう。 そんな Cookie が今どう使われ、 3rd Party Cookie (3rdPC) の何が問題になっているのかを踏まえ、これからどうなっていくのかについて考える。 Cookie のユースケース Web にある API の中でも Cookie はいくつかの点で特異な挙動をする 一度保存すれば、次から自動で送る

逆に、RFC 6749 以外で定義されている認可フローをサポートする場合、新たに別のエンドポイントの実装が必要になることがあります。例えば CIBA（Client Initiated Backchannel Authentication）ではバックチャネル認証エンドポイント（backchannel authentication endpoint）、デバイスフロー（RFC 8628）ではデバイス認可エンドポイント（device authorization endpoint）の実装が求められます。 この記事では、認可エンドポイントとトークンエンドポイントを実装します。サポートする認可フローは認可コードフローのみ、サポートするクライアント・タイプはパブリックのみとします。 2. 注意点 下記の理由、および書かれていないその他の理由により、本実装は商用利用には適していません。 セキュリティー上必須

RFC 6749 (The OAuth 2.0 Authorization Framework) で定義されている 4 つの認可フロー、および、リフレッシュトークンを用いてアクセストークンの再発行を受けるフローの図解及び動画です。動画は YouTube へのリンクとなっています。 English version: Diagrams And Movies Of All The OAuth 2.0 Flows 追記 (2019-07-02) 認可決定エンドポイントからクライアントに認可コードやアクセストークンを渡す方法については、別記事『OAuth 2.0 の認可レスポンスとリダイレクトに関する説明』で解説していますので、ご参照ください。 追記（2020-03-20） この記事の内容を含む、筆者本人による『OAuth & OIDC 入門編』解説動画を公開しました！ 1. 認可コードフロー RF

はじめに 過去三年間、技術者ではない方々に OAuth（オーオース）の説明を繰り返してきました※1,※2。その結果、OAuth をかなり分かりやすく説明することができるようになりました。この記事では、その説明手順をご紹介します。 ※1：Authlete 社の創業者として資金調達のため投資家巡りをしていました（TechCrunch Japan：『APIエコノミー立ち上がりのカギ、OAuth技術のAUTHLETEが500 Startups Japanらから1.4億円を調達』）。Authlete アカウント登録はこちら！ ※2：そして２回目の資金調達！→『AUTHLETE　凸版・NTTドコモベンチャーズ・MTIからプレシリーズA資金調達』(2018 年 2 月 15 日発表) 説明手順 （１）ユーザーのデータがあります。 （２）ユーザーのデータを管理するサーバーがあります。これを『リソースサーバ

はじめに この記事では、OAuth 2.0 の認可サーバーが返す認可レスポンスと、それに伴うリダイレクト処理について説明します。 動画解説のほうがお好みであれば、オンライン勉強会『OAuth & OIDC 勉強会 【認可リクエスト編】』の『3. リダイレクション』をご覧ください。 RFC 6749（The OAuth 2.0 Authorization Framework）には、アクセストークン発行フローが幾つか定義されています（参考：OAuth 2.0 全フローの図解と動画）。 それらのうち、認可コードフロー（RFC 6749, 4.1. Authorization Code Grant）とインプリシットフロー（RFC 6749, 4.2. Implicit Grant）では、クライアントアプリケーションが Web ブラウザを介して認可サーバーの認可エンドポイント（RFC 6749, 3

前回の記事で解説したように、Payment Request API によってウェブでの支払いにおけるユーザーエクスペリエンスは大きく変わる可能性があります。しかし、これが本当にメインストリームになるのか、将来的に自分のサイトを対応させる必要性は出てくるのか？そんな疑問を持つ方は少なくないと思います。 僕はかなり高い確率で、今後ウェブ上でのほとんどの支払いが Web Payments を経由したものに変わっていくと予想しています。この記事では、その理由を説明していきます。 クレジットカードのセキュリティ問題 # あなたはクレジットカードを紛失して再発行した経験はありますか？ クレジットカードは紛失や盗難で番号が漏れて他人に知られてしまった可能性がある場合、カード番号を変更しなければなりません。番号が変わるということは、設定してある自動引落などが全てやり直しになってしまいます。その手続きの大変