複数のウォレットをiPhoneにインストールすると困る話

こんにちは、富士榮です。

先日のMyData JapanカンファレンスではDataSignさんが提供されているOWND Walletへの入場証の発行が可能なことが現地では話題になっていました。

当日のセッションでも代表の太田さんからはオープンソースであるOWND Walletのコードを使ったVESSさんのVESS Walletも紹介され、両方のアプリをインストールした方も多いのではないでしょうか？

しかし、当日実際に両方のウォレットアプリがインストールされている状態だとうまく意図したウォレットに入場証明書が入らない、という課題が発生していました。

これはiOSを少しだけ知っている人なら推測がつくと思いますが、OWND WalletとVESS Walletが同じカスタムURLスキーム（openid-credential-offer://など）を使っていることから「後から」インストールしたアプリが優先されてしまう、というiOSの仕様によって発生します。

OWND WalletかVESS Walletか、くらいの話なら気をつければ特に問題はありませんが、今後ウォレットが乱立してきて「悪意のある」ウォレットが出てきたり、「一見ウォレットに見えない」アプリが出てきた場合に思わぬ事態を招きかねない、という問題を内包しています。

この話は以前紹介したOpenID for Verifiable Credentials関連仕様のフォーマルセキュリティ分析のレポートでも指摘された課題です。

https://idmlab.eidentity.jp/2024/01/openid-for-verifiable-credentials.html

ということで、ちょっと嫌な方法ではあるのですが、各アプリケーションがどんなカスタムURLスキームを使っているのかを調べてみます。

少し古いのとMacにアプリをインストールする必要があるので個人的にはすごく嫌だったんですが、人柱になりました。

このURLを参考にしています。

https://blog.thetheorier.com/entry/extract-url-scheme

https://www.imobie.jp/iphone-tips/extract-ipa-files-from-iphone.htm

ざっくりいうと、

• ipaファイルからURLスキームを抜き出すデスクトップアプリ（実態はPythonスクリプトらしい）
• AnyTrans（商用アプリ。トライアルで試しました）

をMacに入れてあげる必要があります。（さらにいうと自分のAppleアカウントでAnyTransにサインインする必要もあるのでもっと嫌です・・・）

まずはAnyTransで対象としたいアプリをダウンロードしてMacに転送します。個人的にカスタムURLスキームが被っているのを知っているのは先に触れたOWND Wallet / VESS Wallet、あとはxIDアプリとMicrosoft Authenticatorです。

こんな感じでipaファイルが抽出されてきますので、extract_url_schemeを実行していきます。

こんな感じで各アプリがどんなURLスキームを登録しているか見えます。
この例だとMicrosoft AuthenticatorとxIDアプリがopenid-vcというURLスキームを重複登録していることがわかりますね。

これはウォレットエコシステムを作る上で大きな課題となりますので、Chrome 128ベータでも実装されてきているDigital Credential APIが本命になってくるのかと思います。

https://idmlab.eidentity.jp/2024/07/chrome-128digital-credentials-api.html

引き続き要ウォッチですね！

iOS13でSign in with Appleがようやく使い物になってきた

こんにちは、富士榮です。

色々と騒動もあってついつい忘れがちなSign in with Appleですが、先週iOS13が正式に出てきてようやく使い物になってきました。
iPhone11は・・・ボトムズですよね。買ってません。

Sign in with Appleとは

いわゆるAppleのOpenID Connect実装です。iPhoneやMacを持っている人は必ず持っているApple Idを使って自前WebサイトなどへOpenID Connectを使ってログイン出来るようになります。
6月のWWDCで発表されて結構盛り上がりました。と、どうじにOpenID Connectの実装内容についても色々と意見がついてプチ炎上？してました。最近まともになっているようですが。
私もAzure AD B2CやAuth0へ組み込んでみたりしました。

　Azure AD B2Cへの実装
　　https://idmlab.eidentity.jp/2019/06/sign-in-with-appleid-ad-b2c.html
　Auth0への実装
　　https://idmlab.eidentity.jp/2019/06/sign-in-with-appleidaasauth0.html

8月頭には idcon でSign in with Apple特集も開催され一瞬で定員をオーバーするなど、注目度も結構高かった記憶があります。

iOS13未満の環境での課題

Sign in with Appleが発表された当時、まだiOS13はβ版でしたので人柱になっている人たち以外の一般人はあまり恩恵を受けられませんでした。
と、言うのもSign in with Appleでログインを行う都度、メールアドレス＋パスワードの入力に加えてiPhoneへワンタイムコードが飛んでくる、という実装で、せっかく同じApple IdでログインしているiPhoneやiPadでも再度認証が要求されていたためです。

こんなUXでした。

iOS13からのUX

OSに統合されたのでTouch IDやFace IDでそのままログイン出来るようになりました。
素晴らしい！

日本人はiPhoneが大好きなので各種WebサイトのSign in with Apple対応も今後進んでくると思います。（みんながiOS13以上になるのがいつか？という話はありますが）

[LINE Login/LIFF]メールアドレス登録無しでLINEログインできるWebアプリを作るには

こんにちは、富士榮です。

LINEログインを使うと、WebサイトへLINE IDを使って簡単にログインすることが出来ます。

また、LINEログインにはオートログインという機能があり、特定の環境においては端末にLINEアプリがインストールされていれば、ブラウザでLINE IDとパスワードを打ち込むことなく、Universal Linkやインテントを使ってLINEアプリへの遷移、自動的にログインをすることが出来ます。

しかし、このオートログイン、少々適用条件が厳しめです。

https://developers.line.me/ja/faq/ より

iOSの場合
LINE 5.2.0以降：LINEのアプリ内ブラウザでLINEログインv2の自動ログインが可能
LINE 7.5.0以降：SafariブラウザでLINEログインv2の自動ログインが可能
LINE 7.12.0以降：LINEログインv2.1の自動ログインが可能

Androidの場合
LINE 6.3.0以降：外部ブラウザででLINEログインv2の自動ログインが可能
LINE 6.4.0以降：LINEのアプリ内ブラウザでLINEログインv2の自動ログインが可能
LINE 7.14.0以降：LINEログインv2.1の自動ログインが可能

こうなってくると、私のようにiOSでChromeを使っている人は結局IDとパスワードの入力から逃れられず、ソーシャルログインのメリットが目減りしてしまいます。
（もちろん、セッションが永続するので2度目以降は大丈夫なんですが）

Safariの場合：LINEアプリが立ち上がり自動ログインされる

Chromeの場合：初回はログイン画面が表示され、2回目以降は確認だけ行われる

結局のところ、外部ブラウザからの遷移を考えるからこうなるので、LINEアプリ内のブラウザでWebアプリを開いてもらえばこのような問題は起きない話しです。ただし、これまではユーザにアプリ内ブラウザの利用を強制する方法がなく、リッチメニュー（トークルームの下に表示できるカスタムメニュー）を個別に作って対応したりしていた訳です。

こういう時に便利なのが、LIFF（LINE Front-end Framework）です。

　LIFF概要
　https://developers.line.me/ja/docs/liff/overview/

仕組み的には、LINEのカスタムURLスキームを使ってLINEアプリ内のブラウザを立ち上げる、という単純な仕組みです。これまではLINEアプリ内でカメラを立ち上げたり、特定のボットのタイムラインを開くことは出来たのですが、アプリ内ブラウザを立ち上げることが出来なかったので、LIFFの登場によりLINEアプリを外部からコントロールする幅が大きく広がった、と言えるでしょう。

　LINEで利用できるURLスキームの一覧
　https://developers.line.me/ja/docs/messaging-api/using-line-url-scheme/


LIFFを立ち上げるには
　line://app/{liff_app_id}
を指定します。

LIFFアプリを作成する際、特定のURLを開くような形でLINEプラットフォームへ登録するため、カスタムURLスキームで外部からLIFFアプリが呼び出されると、LINEアプリ内であらかじめ登録したWebページが開かれる、という仕組みです。

この仕組みを応用すれば、LINEログインをさせたいアプリを開いたときはLIFFを経由して強制的にアプリ内ブラウザを起動する、ということが出来るので、呼び出し元ブラウザを意識することなくオートログインをさせることが出来るようになります。

では、早速やってみましょう。

◆LIFFアプリを登録する

LIFFはボット（Messaging API）の一部の機能として提供されていますので、LIFFを登録するためのエンドポイントへのPOSTを行う際は、Messaging APIのチャネルのアクセストークンを使います。

具体的には、こんな感じのクエリを投げます。

エンドポイント	https://api.line.me/liff/v1/apps
メソッド	POST
リクエストヘッダ	authorization	Bearer {Messaging APIのチャネルアクセストークン}
	content-type	application/json
ボディ	{ "view":{ "type":"full", "url":"起動したいWebアプリのURL（要https）" } }

上手くいくと、LIFFアプリIDがボディで返ってきます。
{
　"liffId": "xxxxxx"
}

このボディにセットするURLにLINEログインをさせたいWebアプリのURLを指定すればLINEアプリ内のブラウザでアプリを起動することが出来るので、オートログインができるようになります。

◆LIFF経由でWebアプリを呼び出す

後は呼び出すだけですので、User-Agentを見るなりなんなりしてモバイル系ならカスタムURLスキームで呼び出せば問題ありません。

LIFFアプリを外部ブラウザから呼び出します。

LINEアプリ内でWebアプリが起動され、自動ログオンされます。

ちょっとトリッキーではありますが、現段階で様々な環境のユーザをアプリ内ブラウザへ誘導するにはこの方法しかなさそうなので、覚えておくとよいかと思います。

[小ネタ]NAT構成のVMに構成されたAD FSへiOSデバイスを登録する

こんにちは、富士榮です。

今回は完全に小ネタというか自分用のメモです。

普段、BootcampなMacbook AirにWindows 10を入れ、その上でVMware Workstationを動かして、AD FSやMIMを動かして検証してるんですが、VMやAzureだけでクローズできないネタを検証する場合です。

具体的にはiOSやAndroidデバイスなどをAD FSへデバイス登録してデバイス認証をしたい場合、以下が困ります。
・JailbreakしていないiOSだとhosts登録が出来ない
・色々と事情があってVMをNAT構成で動かしているので母艦PC以外からVMへアクセスできない

ということで、対処してみます。

と、言ってもやることは母艦にApacheを立ててForward Proxyにするだけなんですが。

◆Apacheをダウンロードして構成する

Apacheの本家からWindows用のbinaryのダウンロードは出来なくなっているので、本家からリンクされているサイトからダウンロードをして使います。
　http://httpd.apache.org/docs/current/platform/windows.html#down

母艦がWindows 10 Pro x64なので、64bit版をダウンロードしてきました。バージョンは現時点の最新版な2.4.25です。

zipアーカイブを解凍したら少々コンフィグをいじくります。（conf\httpd.confを編集します）
ポイントは、

1. パスを合わせる
2. Proxyに必要なモジュールをロードする
3. Forward Proxyとして構成する
4. ServerNameをつける

の4点です。

では順番に。

１．パスを合わせる

　変更箇所はServerRoot、DocumentRoot、ScriptAlias、cgi-binのディレクトリ設定の4か所です。単にForward Proxyとして使うだけなので変更しなくても問題はありませんエラーが出るので。以下の5行が変更対象です。今回、C:\Tools\Apache以下にモジュールを展開したので環境に合わせて編集します。

ServerRoot "C:/Tools/Apache/Apache24"
DocumentRoot "C:/Tools/Apache/Apache24/htdocs"

    ScriptAlias /cgi-bin/ "C:/Tools/Apache/Apache24/cgi-bin/"

２．Proxyに必要なモジュールをロードする

　必要なモジュールのLoadModule行のコメントアウトを外します。今回AD FSを使うのでhttpsのフォワードも必要なのでmod_proxy_connectも使います。

LoadModule proxy_module modules/mod_proxy.so
LoadModule proxy_connect_module modules/mod_proxy_connect.so
LoadModule proxy_http_module modules/mod_proxy_http.so

３．Forward Proxyとして構成する

　非常に雑な構成ですが、httpd.confの最後に以下を追記します。

  ProxyRequests On
  ProxyVia On
  Listen 8080
  AllowCONNECT 443
 
    Order deny,allow
    Deny from all
    Allow from all
 

４．ServerNameをつける

　これはしなくてもいい設定ですが、Apacheの起動時にワーニングが出るのでとりあえず設定しておきます。

ServerName hoge:80

取り敢えずここまで設定したらOKなので、起動しておきます。
私の場合は検証したい時だけ立ち上げれば良いので、サービス化はせずにコマンドプロンプトから直接起動します。

binディレクトリ配下でhttpd.exeを起動するだけです。

◆母艦からアクセスできるようする（hostsファイルの構成など）

母艦経由でVMへアクセスさせたいので、まずは母艦からアクセス出来るようにネットワークを構成をしてあげる必要があります。

多くの場合、適当な名前（.localとか）でドメインを構成していたりするので、母艦のhostsファイルを使って適切にアクセスできるように構成する必要があります。

後は、念のため母艦からAD FSへアクセスできることを確認しておきましょう。

◆iOS側のProxy設定をする

最後にiOSのWifi設定でProxyサーバに母艦PCを指定します。
尚、当然の事ながら母艦PCへの8080ポートの通信をWindows Firewallで開放しておく必要があります。

iPhoneの設定からWifiを開き、母艦PCと同じアクセスポイントへ接続していることを確認したら、母艦PCのIPアドレスとProxyサーバとして指定した8080番を指定します。

設定はこれで終了です。

◆DRSへアクセスしてデバイス登録する

この状態でiPhoneからAD FSのデバイス登録サービス（DRS）へアクセスして、プロファイルがインストールされるか確認してみます。

DRSのアドレスは
　https://ADFSServer/EnrollmentServer/otaprofile
ですが、当然インターネットにしか繋がっていないiPhoneからVMで動いているAD FSへアクセスは出来ず、DRSへ到達できません。

しかし、今回母艦に立てたProxyを経由することでVM上のAD FSへアクセスでき、無事にプロファイルがインストールできます。

当然、デバイスクレームの取得もできるので、手元でアクセス制御のテストも行うことが出来ます。

まぁ、Azure上にIaaSを立ててインターネットからもアクセス出来るようにすればいいんでしょうが、iOSからアクセスできるようにちゃんとDNS登録が必要だったり、特にDRSの場合はenterpriseregistrationの名前が解決できる証明書を用意しなければいけなかったりするので、手元で済ませられれば手軽なのでこういう方法もありかな～と思っています。

スマートフォンを使ってマイクロソフトアカウント認証を行う

こんにちは、富士榮です。

Windows 10へマイクロソフトアカウントでサインインして、IEもしくはEdgeしか使わない、という人はPCとブラウザのシングルサインオンが有効なので気にすることは無いかも知れませんが、一般人はChromeやFirefoxなども利用していると思いますので、MSDNやLive等のマイクロソフトの提供するサービスを利用する際がマイクロソフトアカウントとパスワードを使ってログインしていると思います。（そして、もちろん2段階認証も使っていると思います）

このように、パスワードをなるべく使わない方向に世の中シフトしてきてはいますが、なかなか一般人の利用方法だと完全にパスワードの利用を無くすのが難しいのも現実です。

※ちなみに以前紹介したWindows 10のPC自体へのログインをスマートフォンで行ったりWindows Helloを使った生体認証を使うと本当にパスワードを使うことなく日々の生活が送れてしまいます。


そこで本日はマイクロソフトアカウントでサインインする際に、パスワードの代わりにスマートフォンを利用する方法を紹介します。
（最近、iOS版アプリが更新されて使えるようになりました）

必要なもの

・マイクロソフトアカウント（～@live.jpなど）
・スマートフォン（iOS、Android、Windows Phone）
・Microsoft Authenticatorアプリ（スマートフォンにインストール）
 ※iTunesストアなどよりインストール

設定（利用の準備）

まず、マイクロソフトアカウントのページ（https://account.microsoft.com）へサインインします。

ログイン後、セキュリティのメニューを開きます。

次にセキュリティ情報の更新の「更新情報」を開きます。

「追加オプション」を開きます。なかなか深い階層に設定がありますね・・・

ここでようやく目的の認証アプリの設定項目が見つかりますので、「本人認証アプリをセットアップ」を開いて設定を行います。

設定画面を開くと、アプリケーションをインストールしたデバイスを選択することになるので、先にアプリをインストールしたデバイスの種類を選択して次へをクリックします。

スマートフォンアプリケーション側での設定を促されるので、アプリ側の設定を行います。この際、アプリ側の設定が終わるまではこの画面の「次へ」をクリックしないでください。

アプリを開くと設定するアカウントの種類を選択させられるので、「個人のアカウント」を選択します。

ここでマイクロソフトアカウントでのサインインを要求されるので、スマートフォンサインインを使いたいマイクロソフトアカウントでサインインします。さすがにここはパスワードでのサインインです。

設定が完了すると画面上にワンタイムパスワードが羅列された画面になるので、先のブラウザに戻って「次へ」をクリックします。

これで設定は完了です。

サインインしてみる

サービスはなんでもいいです。MSDNやOutlook、Azure Portalなどでも大丈夫です。

アカウント名を入れると通常のパスワード入力画面に飛びますが、設定がうまくいっていればこの際「代わりにアプリを使用する」というリンクが出てくるようになるので、このリンクをクリックします。

すると、アプリへ認証要求が飛び、ブラウザ側はアプリ側の承認を待機します。

アプリ側はこんな感じでサインイン要求が来るので、「承認」をタップします。
この際、TouchIDが使えるiPhone/iPadであればTouchを求められます。

上手くいくとブラウザ側でのログインが完了し、対象のサービスへ遷移します。※この例ではAzure Portalへアクセスしています。

これまで、Windows 10、Edge/IE、組織アカウントの組み合わせで限定的に使えていたパスワードレス認証の範囲が、他のブラウザへも広がってきており、いよいよパスワードを使うことなく生活できる日も近くなってきた感があり、今後の展開を含め非常に楽しみですね。