パスワードレス認証導入その後｜ころちゃん
ころちゃんです。本記事は Digital Identity技術勉強会 #iddance Advent Calendar 2020 21日目の記事になります。開発ブログも兼ねています。 19日目の猫氏の記事でも引用してもらっていますが、今年はbosyuにメールアドレスログイン機能を追加したので、今年のうちに、書ける範囲で、振り返りしておきたいなと思い、アドカレに乗っかりました。 生体認証の仕組みの話を書こうと思いましたが、ネトゲの拡張がリリースされてしまい進捗が無になっているので断念。 前提・リリース時点で出した記事はこちら ・導入前: Twitter, Facebook によるSNSログイン ・導入後: 上記 + メールアドレスログイン ・Email OTP（One-Time-Password）の話で、FIDOの話ではない ・要求としては「SNSとは切り離された何かで認証したい」 メアドロ
パスワードが不要なメール認証の話と、Sign in with Apple に関わる App Store Review ガイドラインの話 | Annict
パスワードが不要なメール認証の話と、Sign in with Apple に関わる App Store Review ガイドラインの話 ソーシャルログイン (Twitterでログインとか) のプロバイダが増える度に無限に対応していくのは破綻しそうだなと思ったので、MediumとかSlackがやってるようなログイン用のメールを送ってパスワード無しでログインできる仕組みを実装しています。 上の画像は開発中のもので、まだリリースしていないです。 これをやり始めたきっかけが Sign in with Apple 対応で、今はソーシャルログインできるサービスのiOSアプリを作るときは Sign in with Apple を追加しないとリジェクトされるとのことです。 https://developer.apple.com/jp/app-store/review/guidelines/#sign-in
OAuth 2.0 / OpenID Connectにおけるstate, nonce, PKCEの限界を意識する - r-weblife
おはようございます、ritouです。ちなみに予約投稿なのでまだ寝てます。 本日のテーマはこちらです。 OAuth/OIDCのstate,nonce,PKCE使ってもClient/RPがしょーもなかった場合のServer/OP側の限界についてのブログ書いてる。— 👹秋田の猫🐱 (@ritou) July 6, 2019 OAuth 2.0で言うところのClientの視点から、ここに気をつけて実装しましょうという話ではありません。 OAuth 2.0で言うところのServerの視点からみて、Clientにこんな実装されたらたまんねぇなっていうお話です。 最終的には一緒な気もしますが、とりあえず始めます。 state OAuth DanceにおけるCSRF対策としての state パラメータについて簡単に整理します。 Clientがセッションに一意に紐づく値として生成、管理 ClientがA
トークンを利用した認証・認可 API を実装するとき Authorization: Bearer ヘッダを使っていいのか調べた - Qiita
トークンを利用した認証・認可 API を実装するとき Authorization: Bearer ヘッダを使っていいのか調べたAPIOAuthWeb TL;DR HTTP でトークンを利用した認証・認可をする手法として RFC 6750 がある OAuth に限らず、トークンを利用して認証・認可する機構の一部として Authorization: Bearer ヘッダを使うことができる 使い方について詳しくはこの記事の下のほうに書いた 要求 トークンを利用した認証・認可機構を持つ API を作りたい クライアントがトークンを HTTP リクエストに含めて送信し、サーバはトークンを検証してリソースへのアクセスを許可したい Authorization: Bearer トークン ヘッダでトークンを送る API あるよね、ああいうやつ 疑問 Authorization: Bearer ヘッダは OA
OAuth 2.0のAccess TokenへのJSON Web Token(JSON Web Signature)の適用 - r-weblife
こんばんは、ritouです。 久々の投稿な気がしますが、今回はOAuth 2.0のリソースアクセス時の設計の話です。 ずーっと前から書こうと思いつつ書いてなかったので、ここに書いておきます。 出てくる用語や仕様は、下記の翻訳リンクを参照してください。 The OAuth 2.0 Authorization Framework JSON Web Signature (JWS) 想定する環境 わりとよくある環境を想定しています。 OAuth 2.0で認可サーバーとリソースサーバーがある 認可サーバーがAccess Tokenを発行 リソースサーバーがAPIリクエストに含まれるAccess Tokenを検証する よくある実装とその悩みどころを、JSON Web Token(JSON Web Signature)により軽減できるかもという話です。 よくある実装 : Access Tokenに一見ラ
Net::Twitter::UserStreamsというモジュールを書きました - 猫型開発者
cpan形式でモジュールを作る練習として、Net::Twitter::UserStreamsというモジュールを書きました。 このモジュールは、miyagawaさんのAnyEvent::Twitter::Streamの、UserStreamsを扱うことに特化した薄いラッパーです。思想としては、 AnyEventの層を隠蔽する ネットワークの層も隠蔽する とにかく手軽にUserStreamsをトラッキングできる という思想で作りました。そのため、モジュール内で$cv->recvしているしモジュール内で無限ループしているという変な実装になっています。なので、「挙動を自分できちんと握りたい」という向きにはオススメできない感じです。一方、AnyEventとかPerlとかよくわかんないんだけど、たとえばフォセッタ (@Fossetta_Tokyo) | Twitterみたいなbotを作りたい、なんて時
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
各社のログインAPIで返ってくるIDは何であるのかと、PPIDの現状について