2024年6月21日にデジタル庁からデジタル認証アプリの発表がありました。 このデジタル認証アプリで何ができるのか、ざっくり整理してみました。 この記事で対象としている方 デジタル認証アプリの概要についてざっくり理解したい方 デジタル認証アプリについて今北産業してほしい方 この記事では技術的な話はなるべく避け、全体像を整理していきます。 技術的な話を理解したい方は、参考リンクより他の方が書かれた記事を参照してみてください。 「デジタル認証アプリ」はどんなものか？ 「デジタル認証アプリ」は、マイナンバーカードを使った認証や署名を、安全に・簡単にするための、デジタル庁が提供するアプリです。 （デジタル認証アプリサービスサイトより引用） デジタル認証アプリは、デジタル庁が提供するデジタル認証アプリサービスAPIと組み合わせて1つのサービス（デジタル認証アプリサービス）を構成しています。デジタル認
長いので答えだけ知りたい 暗証番号(PIN)無しで利用者証明が可能な特定機関認証を使用しているからです。 特定機関認証は特定機関認証用の公開鍵証明書と秘密鍵をあらかじめ提供されている必要があるため、汎用的には使えません。 マイナンバーカードの保険証利用について マイナンバーカードの保険証利用が宣伝されるようになりました。 マイナンバーカードの保険証利用について（被保険者証利用について）より引用 マイナンバーカードの健康保険証利用申込はマイナポータルなどから行います。 マイナンバーカードの健康保険証利用について～医療機関・薬局で利用可能～より引用 このマイナンバーカードの保険証利用ではマイナンバーを利用することはありません。マイナンバー法により定められた「特定個人情報の提供の制限」で認められる利用範囲ではないからです。このことは公式のFAQにも書いてあります。 Ｑ９．医療機関・薬局がマイナン
JWS/JWE/JWT/IDトークンの包含関係 JWS (JSON Web Signature) と JWE (JSON Web Encryption) の直列化方法には、それぞれ JSON 形式とコンパクト形式がある。 JWT (JSON Web Token) は JWS か JWE だが、いずれにしてもコンパクト形式である。仕様でそう決まっている。 仕様により、ID トークンには署名が必要なので、ID トークンは JWS もしくは「JWS を含む JWE」という形式をとる。 ID トークンは「JWE を含む JWS」という形式はとらない。なぜなら、仕様により、ID トークンを暗号化する際は「署名してから暗号化」という順番と決まっているため。 アクセストークン/JWT/IDトークンの包含関係 アクセストークンの実装が JWT だとは限らない。 仕様により、ID トークンは必ず JWT で
JWTとは JSON Web Tokenの略。ジョットと読むらしい。 ざっくりいうとJsonに電子署名を加え、URL-Safeな文字列にしたTokenのこと 正確にいうと、電子署名を使用する方式はJWS（JSON Web Signature）と呼ばれ、別途暗号化を使用するJWE（JSON Web Encryption）も存在する。よく見かける説明はJWS方式のほう。 JWS方式の場合、電子署名であり暗号化ではないため、中身を見ることは可能。但し改ざんはできない、という仕組み。 実際のユースケースで言うと、サーバ側で認証情報が入ったJsonを加工（電子署名を加える等）し、JWTにしたのち、それを認証Tokenとしてクライアントに渡す。クライアントはそのTokenを認証Tokenとして使用する。 仕組みについては調べればたくさん出てくるのでそちらを参照したほうが良いかと思います。 この記事では
ちょっとでもセキュリティに自信がないなら、 Firebase Authentication を検討しよう （※ こちらの参照記事の内容自体に不備があるとか甘いとか指摘するものではないんですが、勝手に枕として使わせてもらいます） 上記記事は、Firebase Authenticationが提供するJavaScript APIを使ってJWTのトークンを取得し、自前のサーバにHTTPのヘッダで送りつけて検証をさせることで、認証の仕組みをセキュアかつかんたんに実現しよう、という内容です。 このようにJavaScriptのAPIでトークンを発行して自前バックエンドのAPI認証につかう方法はAuth0のSDKなどでも行われていますので、IDaaSをつかってSPAを開発する場合には一般的なのかもしれません。 話は変わりますが、SPAの開発に携わっている方は「localStorageにはセッション用のトー
はじめに 普段はWeb開発を生業としている おりばー(@oliver_diary) です。 今年の4月から情報処理安全確保支援士として、社内のセキュリティ向上に努めているのですが、その取り組みの一つとして社内Slackに毎週セキュリティトピックを公開しています。 毎週続けて3ヶ月が経過しましたが、社内だけに閉じておくのは勿体ないと思ったので、記事としてまとめて投稿します。みなさんのセキュリティ意識向上の助けになればと思います。 またセキュリティ研修用に使用したアプリケーションの記事も公開しているので、そちらも併せてご覧ください。 Gitの脆弱性（2020/04/23） みなさん、既にバージョンをあげている方もいると思いますが、Gitにとても深刻な脆弱性が発見されました。 http://www.security-next.com/114201 https://github.com/git/g
はじめに X.509 証明書について解説します。(English version is here → "Illustrated X.509 Certificate") ※ この記事は 2020 年 7 月 1 日にオンラインで開催された Authlete 社主催の『OAuth/OIDC 勉強会【クライアント認証編】』の一部を文書化したものです。勉強会の動画は公開しており、X.509 証明書については『#4 X.509 証明書（１）』と『#5 X.509 証明書（２）』で解説しているので、動画解説のほうがお好みであればそちらをご参照ください。 1. デジタル署名（前提知識） この記事を読んでいただくにあたり、デジタル署名に関する知識が必要となります。つまり、「秘密鍵を用いて生成された署名を公開鍵で検証することにより」、「対象データが改竄されていないこと」や「秘密鍵の保持者が確かに署名したこと
これまでのLinuxでは、ユーザーの追加はuseraddで行われ、ホームディレクトリは/home以下にディレクトリとして作られ、ユーザーのアカウントは/etc/passwd、/etc/group、/etc/shadowで管理されていました。 これからは、systemd-homedがその全ての仕事を置換することになります。 ※タイトル詐欺感がありますが、従来の方式も並行して使えます。安心してください。 systemd-homedとは？ systemd バージョン245で追加された、ユーザー管理デーモン。実体はsystemdのサービスユニットファイルで、systemd-homed.serviceとして起動されます。 今後、ユーザーの管理や認証はsystemd-homed（以下、 homed ）によって行われることになるようですね。 出典が無く間違いだったため、訂正しました。systemd-ho
1passwordのアイテム編集画面で、フィールドタイプを眺めててふと思った。「ワンタイムパスワードってあるけど、これ、AWSで多要素認証するときの『仮想MFAデバイス』に使えるのでは」と。結論から言えば、使えた。快適。でもこれは多分「人をダメにするナントカ」的な快適さだ。やっちゃいけないやつだ。 AWSでは、AWSアカウントの管理者であるrootユーザー（メールアドレスでログインする人）と、利用者であるIAMユーザー（ユーザーIDでログインする人）のどちらでも、多要素認証（MFA：Multi-Factor Authentication）を設定して認証を強化できる。 認証方法はパスワード認証＋ワンタイムパスワード（当人が知っていること＋当人が持っているもの） ワンタイムパスワードの生成には、専用のデバイスであるU2FセキュリティキーやハードウェアMFAデバイス、スマホアプリである仮想MFA
今回は、実際のアプリケーション開発を意識して、Spring Seucirtyが提供しているデフォルト動作をカスタマイズする方法をいくつか紹介していきたいと思います。 シリーズ 第1回：Spring Security 5でサポートされるOAuth 2.0 LoginをSpring Bootで使ってみる 第2回：Spring Security 5でサポートされるOAuth 2.0 Loginの処理の流れを(大まかに)理解する 第3回：Spring Security 5でサポートされたOAuth 2.0 Loginの処理の流れを(深く)理解する 動作検証バージョン Spring Boot 2.0.0.M7 Spring Security 5.0.0.RELESAE カスタマイズポイント 本エントリで紹介するカスタマイズポイントは以下の５つです。本エントリで紹介するのは、Spring Securi
前回「Spring Security 5でサポートされるOAuth 2.0 Loginの大まかな処理の流れを理解する」で大まかな処理の流れを紹介したので、それらをさらにブレークダウンした処理の流れなどをみていきたいと思います。 前提バージョン Spring Boot 2.0.0.M7 Spring Security 5.0.0.RELEASE 認可要求 クライアントAPからプロバイダの認可画面を表示（＝正確にはクライアントからプロバイダへリダイレクト）する時の処理フローをみていきます。前回紹介した図だと、赤線で囲んだところがここでの説明対象になります。 認可要求(認可画面表示要求)が行われると、OAuth2AuthorizationRequestRedirectFilterを起点として、ClientRegistrationRepository、AuthorizationRequestRep
Spring Security 5の目玉であるOAuth 2.0(& OpenID Connect 1.0)の認可サーバと連携したログイン機能を、Spring Boot上で使う方法を紹介します。（今回はSpring Boot上で使う方法の紹介だけにとどめます→仕組みの話は乞うご期待！！） 動作検証バージョン Spring Boot 2.0.0.M7 Spring Security 5.0.0.RELEASE Tomcat 8.5.23 NOTE: 2017/12/2 : Spring Boot 2.0.0.M7 (Spring Security 5.0.0.RELEASE)ベースに書き換えました。 OAuthプロバイダ GitHub Note: ちなみに・・・Spring Securityは、GitHubの他に、Google、Facebook、Oktaをデフォルトでサポートしています。 デ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
