ラベル Facebook の投稿を表示しています。 すべての投稿を表示
ラベル Facebook の投稿を表示しています。 すべての投稿を表示

2024年7月10日水曜日

食べログのFacebook連携の終了とトラッキングの許可問題

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

みんな大好き食べログですが、しばらく前からFacebook連携でログインしようとするとトラッキング許可を求められるようになっていました。(アプリ利用の場合のみ)


なんだか微妙だなぁ、と思ってアプリの利用を諦めていたんですが、こんな記事を見つけました。

【改善済み】(iOS)Facebookログインを利用していると、トラッキングに関するエラーメッセージが表示される


この記事をみると「FacebookアカウントPikmin Bloomに連携していると、突然トラッキングに関するエラーメッセージが表示されるという問題が報告されています。」とありますのでアプリは異なれど似たような話に見えます。
ただ、このアプリではiOS 17.5.1にしたら解消されたとありますが、食べログアプリでは解決されていませんでしたが。。。

と思っていたら、以下のお知らせが。
【重要】Facebookログイン機能終了のお知らせ

8月4日までに他のログイン方法でログインできるようにしておかないといけませんね。
準備をしておきたいと思います。

2020年5月20日水曜日

Build速報!FacebookでAzure ADへログインする

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

Buildですね。リモート開催になって日本からでも参加しやすくなって睡眠時間が削られる日々をお過ごしだと思います。

今回も色々とAzure ADに関する新機能の発表がありました。

詳しくはAlexのBlogを参照してもらえれば良いのですが、今回はAzure AD B2Bの直接フェデレーションへのFacebookログインの登場(Public Preview)の話です。

AlexのBlog)
https://techcommunity.microsoft.com/t5/azure-active-directory-identity/build-2020-fostering-a-secure-and-trustworthy-app-ecosystem-for/ba-p/1257360

Azure AD B2Bの直接フェデレーションについてはこれまでも取り上げてきましたが、Googleに対応してから約2年、ここに来てFacebookに対応しました。

Googleとの連携の件
https://idmlab.eidentity.jp/2018/08/azure-ad-b2bgoogleid.html

カスタムドメイン vs 直接フェデレーションの件
https://idmlab.eidentity.jp/2020/05/azure-adbyoid.html



もはやB2Bとは?というしかない状態なのですが、早速触ってみましょう。

外部アイデンティティプロバイダの設定

これまでも紹介したことのある画面です。Azure ADのポータルを開き、External Identitiesメニューから「すべてのIDプロバイダー」を開くと「Google」に加えて新たに「Facebook」が選べるようになっています。


ここでFacebookを追加して、AppIdとAppSecretを追加すれば基本は終わりなのですが、設定前に外部ユーザによるサインアップを許可しておく必要があります。
「外部コラボレーションの設定」メニューを見ると、新しく「ユーザーフローによるゲストセルフサービスサインアップを有効にする」という設定が追加されているので有効にしておきましょう。

後はFacebook Developerコンソールで作成したアプリケーションのAppIdとAppSecretを設定すれば終わりです。

Facebook側の設定方法はAzure AD B2Cのドキュメントに記載がありますので、1点を除いてこちらをそのまま使って大丈夫です。
https://docs.microsoft.com/en-us/azure/active-directory-b2c/identity-provider-facebook

その1点とは、そうですredirect_uriです。
直接フェデレーションの場合にFacebookに設定するredirect_uriはどうなるのか?というと、
https://login.microsoftonline.com/te/{テナントID}/oauth2/authresp
となります。

ここまで設定を進めると、ユーザーフローからAzure ADにアクセスするためのアプリケーション「aad-extensions-app」が自動的に登録されます。


ちなみに、このアプリケーションを削除すると面倒なことになるので、消さないようにしてください。
万一消してしまったらAzure AD B2Cでのb2c-extension-appと同じように回復をしてください。
参考)B2Cでの回復手順
https://docs.microsoft.com/ja-jp/azure/active-directory-b2c/extensions-app


ユーザーフローの登録

外部IDプロバイダの設定が終わったら、次はユーザーフローの登録です。
基本この辺りもAzure AD B2Cと同じです。


ユーザーフローの名称(ポリシー名となります)、利用するIDプロバイダ、連携する属性を設定していきます。
尚、属性は標準で用意されているもの以外に「カスタムのユーザー属性」メニューから自分で好きな属性を追加することもできます。

これでIDプロバイダとユーザーフローの登録はおしまいです。

アプリケーションの登録

次に、先ほど作成したユーザーフローを使ってサインアップやサインインを行う対象となるアプリケーションを登録します。
ポイントは、APIのアクセス許可で「User.Read」スコープに対して管理者による同意をしておくこと、です。現状のユーザーフローでのユーザ作成やログイン時にユーザ自身による同意が上手く取れない?のでこの設定は入れておく必要がありそうです。

ユーザーフローとアプリケーションの紐づけ

アプリケーションを作成したら、先に作成しておいたユーザーフローを使う様に構成をします。
先ほどのExternal Identitiesメニューに戻り、先ほど作成したユーザーフローを開きます。アプリケーションに関する設定項目がありますので、ここで作成したアプリケーションを指定します。

これで一通りの設定は終了です。

動作確認

では早速動かしてみます。

このアプリケーションにアクセスする為には、以下のパラメータをつけてAuthorizationエンドポイント(https://login.microsoftonline.com/{テナントID}/oauth2/authorize)へアクセスする必要があります。(通常のOpenID Connectのアプリケーションと同じです)

  • client_id={登録したアプリのClient Id}
  • response_type=id_token
  • scope=openid
  • nonce={生成したnonceの値。テストなら何でもOK}
  • redirect_uri={登録したアプリのredirect_url}

今回、アプリケーションとしてはhttps://jwt.msを使ったのでこんなURLになります。
https://login.microsoftonline.com/{テナントID}/oauth2/authorize?client_id={クライアントID}&response_type=id_token&scope=openid&nonce=hoge&redirect_uri=https:%2F%2Fjwt.ms

実行してみると、いつものサインイン画面になるので、まずはアカウントを作成します。

アカウントの作成画面に「Facebookアカウントでサインイン」というメニューが出来ています。
ここでFacebookアカウントでサインインすると、Azure ADへのアカウント登録を行う際に追加で登録するアカウントを入力する画面が出てきます。

続行するとアカウントがAzure AD上に登録されます。
アカウントタイプはゲスト、ソースはFacebookになっているのがわかります。


ちなみに登録後、サインインする場合はサインインオプションをクリックするとFacebookログインのメニューが出ていますので、そちらを使ってサインインします。


いかがでしょうか?
基本はAzure AD B2Cの機能の一部を通常のAzure ADの直接フェデレーション向けに開放しただけなので、Azure AD B2Cに慣れている方は直感的に理解できると思います。

しかし、冒頭にも書きましたが、こうなってくると「B2Bとは?」という疑問がやはり出てきますが大人しくしておきましょう。

おまけ

たまたまテストに使ったAzure ADにG-SuiteとのSSO設定があったので、SAMLの属性マッピングの調整をちょこっとして、GmailにAzure ADの直接フェデレーションを使ってFacebookアカウントでログインする、というくだらないものを作ってみたので動画を貼っておきます。

2018年4月28日土曜日

Microsoft Authenticatorアプリが設定のバックアップ・リカバリをサポート、しかし・・・

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

みなさん、多要素認証してますか?
アイデンティティは不正利用されている、という前提で運用しないといけない世の中になってきているので、IDとパスワードが盗難されても不正にログインされない様に多要素認証を有効にするのは大人のマナーです。もしくは、少なくともログイン・アラート(知らないログインがあったら通知してくれる機能)が使える認証システムを使う、くらいはいしないとダメな世の中です。
そういえば昨年のde:codeでもこんな話をしてました。

結局、ID盗難って本人が気が付きにくいところが一番の問題なんですよね。


と、言うことでMicrosoftもAuthenticatorアプリをiOS/Android/Windows Mobile向けに提供しており、私もAzure ADアカウント、Microsoftアカウントに加えてGoogleやFacebook、Amazonなどのアカウントの多要素認証をこのアプリでやっています。

が、機種変更などでアプリを再インストールすることになると実は非常に面倒です。全ての多要素認証設定を再度1からやり直さないといけないので、このアプリがないとログインできないような状態になってしまっているサービスがあると詰みます。

そこで登場したのが、ずっとリクエストが上がっていた多要素認証設定のバックアップとリカバリ機能です。

公式Blogでのアナウンス
 Microsoft Authenticator Account Backup and Recovery: Coming soon to an iOS device near you!
 https://cloudblogs.microsoft.com/enterprisemobility/2018/04/24/microsoft-authenticator-account-backup-and-recovery-coming-soon-to-an-ios-device-near-you/


機能を有効化するためには以下の条件を満たす必要があります。
・iOS版であること(残念ながらまだAndroid版では使えません)
・Authenticatorアプリのバージョンが5.7.0以降であること
・Microsoftアカウント(個人アカウント)があること


早速使ってみましょう。
と、その前に本ポストのタイトルに書いた「しかし・・・」の部分が気になりますよね?そう、実は組織アカウント(Azure AD/Office365)の多要素認証はリカバリできないんです。結局は再度QRコードの読み込みから開始なので、管理者にリセットしてもらう必要があります。
また、多要素認証設定済みのMicrosoftアカウントで設定をバックアップすると、リカバリ時に当該のMicrosoftアカウントでログインを求められますが、当然そのMicrosoftアカウントの多要素認証は今からリカバリしたい設定の中に入っているので、アプリで多要素認証は出来ません。他の方法(メールとかSMSでの回復)を設定していないとこれも詰みます・・・


こんな罠だらけの新Authenticatorですが、Googleなどの他の多要素認証はちゃんとリカバリしてくれる(はず)なので一応便利です。(Googleしか試してないのでAmazonとかFacebookが大丈夫かどうかは知りません)


とは言え、気を取り直して試してみます。
アプリを起動して、設定メニューを開くと「バックアップ」という項目が増えています。

おもむろに自動バックアップをONにするとMicrosoftアカウントが求められます。
この画面だけを見るとバックアップはOneDriveとかに保存されるのかな?と思うんですが、アプリを英語モードで起動すると実はこの画面の前にiCloudに保存する、というメッセージが出てきます。
これを見るとバックアップはiCloudにされ、リカバリする時にMicrosoftアカウントで認証することで保険をかけてる、ということなんだと思います。

Microsoftアカウントを追加すると回復アカウントとして表示されます。

後は、おもむろにアプリを消して再インストールしてみます。
まっさらの状態で起動してくるので、「回復の開始」からリカバリをしてみます。

回復に使うMicrosoftアカウントを選択し、ログインしましょう。
ここではアプリ内ブラウザが前に設定した時のMicrosoftアカウントを覚えてくれていたので選択するところから始まっていますが、機種変更などの場合はアカウントを追加するところからスタートですね。
と、ここで先ほど書いた通りのハマりポイントその1です。
このMicrosoftアカウントに多要素認証の設定をしていたので、ログイン時に多要素認証を要求されます。
運良く、実験した時は別のデバイスで多要素認証する様に構成していたので、難を逃れました。


しかし、別のデバイスで認証する構成にしていたが故に不思議なことが起きてしまいます。発生した現象は後述するとして先に進めましょう。

アカウントの回復完了、と表示されるのですが「セキュリティ上の理由から、一部のアカウントで追加の検証が必要です」と出て、Azure ADのアカウントに!マークがついています。

これが先ほど書いた微妙な点です。
Azure AD/Office365のアカウント(組織アカウント)のリカバリは出来ないんです。
回復するには再度QRコードをスキャンする必要があるので、別の方法で何とかログインするか管理者に多要素認証設定をリセットしてもらうしかありません・・・

今回は管理者でリセットしました。Azure ADのポータルからMFA設定を開いてユーザを検索、Manage user settingsを開きます。

再度ユーザが多要素認証設定を設定する様に要求します。

これで再設定をすると一応リカバリされます。
ちゃんとAzure ADアプリへの多要素認証ログインもできました。もちろんGoogleについてはGoogle側で何のリカバリ処理も必要なく、ちゃんと多要素認証ログインできます。


ちょっとおかしなことになってますよね?
気が付いた方いますか?




そうです、リカバリした端末側の多要素認証設定に、リカバリに使ったMicrosoftアカウントのエントリが勝手にできています。
私は別の端末でこのMicrosoftアカウントの多要素認証をしていますので、2つの端末に同じMicrosoftアカウントの多要素認証エントリが存在している状態になります。

試しに、このMicrosoftアカウントでサービスにログインしてみます。

すると、なんと2つの端末に通知が来ます・・・


はい、バグだと思います。
(と思いましたが、Microsoftアカウントの場合は複数の端末で多要素認証をさせることができるので、こういう仕様なんだと思います)

ちなみに、どちらで承認してもちゃんとログインできます。

うーむ・・・



と、若干微妙な感じではありますが、少なくともGoogleの多要素認証はちゃんとリカバリできたので、楽にはなりました。
皆さんも使ってみましょう。

2015年10月9日金曜日

[Azure AD]Azure AD B2Cを利用してソーシャル認証するアプリケーションを開発する

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

先日Public Previewが公開されたAzure Active Directory B2C(Azure AD B2C)を使うと、これまでAccess Control Service(ACS)が担ってきたコンシューマ・アイデンティティ・プロバイダを使った認証をサポートするアプリケーションを開発することができます。

参考)
・公式Blogでの発表
 Azure AD B2C and B2B are now in Public Preview!
 http://blogs.technet.com/b/ad/archive/2015/09/16/azure-ad-b2c-and-b2b-are-now-in-public-preview.aspx

・安納さんによる世界一はやいまとめ資料
 https://docs.com/junichia/8538/azure-ad-b2c-preview-v0-6


ASP.NET IdentityやACSでも同じようなことが出来るので、今後どのようにすみ分けていくのかは要注目ですが、まずは手始めにOpenID Connectに対応しているものも、そうでないものも含め各種IdPをAzure AD B2Cを経由することによりOpenID Connect対応のIdPにすることができる、という点でアプリケーション開発者から見ると利点があると思われます。

早速、これまでAzure ADやAD FSのOpenID Connect対応を検証するために書いたコードをどこまで再利用できるのか?を確認してみたいと思います。

参考)過去のポスト
 [Azure AD]App Model v2.0を利用して組織内外共用のアプリケーションを開発する
 http://idmlab.eidentity.jp/2015/08/azure-adapp-model-v20.html

 [AD FS]OpenID Connectに対応した次期AD FSを試す
 http://idmlab.eidentity.jp/2015/08/ad-fsopenid-connectad-fs.html


◆OpenID Connect関連のパラメータを確認する
まずは、Azure AD B2CのOpenID Connect関連パラメータをwell-known/openid-configurationエンドポイントから覗いてみます。
エンドポイントアドレスは、
https://login.microsoftonline.com/{tenant}.onmicrosoft.com/v2.0/.well-known/openid-configuration?p=B2C_1_signin
です。

{
  "issuer": "https://login.microsoftonline.com/xxxxxx/v2.0/",
  "authorization_endpoint": "https://login.microsoftonline.com/xxxx.onmicrosoft.com/oauth2/v2.0/authorize?p=b2c_1_signin",
  "token_endpoint": "https://login.microsoftonline.com/xxxx.onmicrosoft.com/oauth2/v2.0/token?p=b2c_1_signin",
  "end_session_endpoint": "https://login.microsoftonline.com/xxxx.onmicrosoft.com/oauth2/v2.0/logout?p=b2c_1_signin",
  "jwks_uri": "https://login.microsoftonline.com/xxxx.onmicrosoft.com/discovery/v2.0/keys?p=b2c_1_signin",
  "response_modes_supported": [
    "query",
    "fragment",
    "form_post"
  ],
  "response_types_supported": [
    "code",
    "id_token",
    "code id_token"
  ],
  "scopes_supported": [
    "openid"
  ],
  "subject_types_supported": [
    "pairwise"
  ],
  "id_token_signing_alg_values_supported": [
    "RS256"
  ],
  "token_endpoint_auth_methods_supported": [
    "client_secret_post"
  ],
  "claims_supported": [
    "emails",
    "sub",
    "idp"
  ]
}



これはマイクロソフトの悪い癖だと思うんですが、エンドポイントのアドレスにクエリパラメータをつけるのはちょっと頂けない感じですね。。。
実際にアプリケーションを開発する時にはConfiguration情報から取得したエンドポイントアドレスに他のパラメータをつけて処理を行うわけなので、クエリパラメータが2重についてエラーが起きてしまいます。。。
ここはAzure AD B2Cを使ったアプリケーション開発をする際の注意点ですね。


◆クライアント登録を行う
Azure AD B2Cの管理は新しいAzureポータルから行います。
このあたりの細かい設定方法は別の機会に紹介したいと思いますが、といあえずクライアント(アプリケーション)を登録してclient_idとclient_secretを取得しないと始まりませんので、まずは登録します。



◆アプリケーションを開発する
既存のOpenID Connect/RP(アプリケーション)のコードの再利用性を確認するのが目的なので、以前のポストで使ったPHPアプリケーションを再利用します。

完全互換であれば、
・authorization_endpoint
・token_endpoint
・client_id
・client_secret
・redirect_uri
を今回の環境に合わせて修正すればそのまま動くはずです。

早速修正してみました。


これで実行すると、、、404エラー来ました・・・。
先ほどのエンドポイントアドレスにクエリパラメータが入っているので変なエンドポイントへアクセスしてしまっています。
仕方がないので、認可エンドポイントへのGETリクエストのパラメータを'?'ではなく、'&'で連結します。



基本はこれで動くようになりましたが、id_tokenのフォーマットが微妙に違うようです。
具体的にはemailsクレームがマルチバリューで返ってくるので、jsonのパースをちゃんとしてあげないといけません。
例えばGoogle+だと以下のようなid_tokenがかえってきます。
{
  "exp": 1444322056,
  "nbf": 1444318456,
  "ver": "1.0",
  "iss": "https://login.microsoftonline.com/xxxx/v2.0/",
  "acr": "b2c_1_signin",
  "sub": "Not supported currently. Use oid claim.",
  "aud": "60a26a60-1c47-497c-b4c3-5cea0f1bc293",
  "iat": 1444318456,
  "auth_time": 1444318456,
  "idp": "google.com",
  "emails": [
    "xxx@gmail.com"
  ]
}



◆実行してみる
今回はGoogle+およびFacebookを使ってサインインする様にAzure AD B2Cを構成してみました。
それぞれの実行結果を確認してみます。

まずはアプリケーションへアクセスするとAzure AD B2Cのログイン画面へ遷移します。
デフォルト画面なので恐ろしくシンプルな画面です。
ここにあらかじめ設定しておいたアイデンティティ・プロバイダが出てきます。



初回アクセス時は認可の確認が求められますので許可すると、クレームが取得できます。
(ちなみに本当の初回はソーシャルIDでサインアップする必要があります。こちらの手順は別途紹介します)

Google+でサインインした場合



Facebookでサインインした場合




どちらの場合もsubが取得できないんですね。。。
今後にいろいろと期待です。


参考:今回利用したコード)
<?php

// パラメータ類
$authorization_endpoint = 'https://login.microsoftonline.com/xxxx.onmicrosoft.com/oauth2/v2.0/authorize?p=b2c_1_signin';
$token_endpoint = 'https://login.microsoftonline.com/xxxx.onmicrosoft.com/oauth2/v2.0/token?p=b2c_1_signin';
$client_id = '60a26a60-1c47-497c-b4c3-5cea0f1bc293';
$client_secret = 'xxxx';
$redirect_uri = 'https://xxxx.azurewebsites.net/index.php';
$response_type = 'code';
$state =  'hogehoge'; // 手抜き
$nonce = 'fogafoga'; // 手抜き

// codeの取得(codeがパラメータについてなければ初回アクセスとしてみなしています。手抜きです)
$req_code = $_GET['code'];
if(!$req_code){
    // 初回アクセスなのでログインプロセス開始
    // GETパラメータ関係
    $query = http_build_query(array(
        'client_id'=>$client_id,
        'response_type'=>$response_type,
        'redirect_uri'=> $redirect_uri,
        'scope'=>'openid',
        'state'=>$state,
        'nonce'=>$nonce
    ));
    // リクエスト
    header('Location: ' . $authorization_endpoint . '&' . $query );
    exit();
}

// POSTデータの作成
$postdata = array(
    'grant_type'=>'authorization_code',
    'client_id'=>$client_id,
    'code'=>$req_code,
    'client_secret'=>$client_secret,
    'redirect_uri'=>$redirect_uri
);

// TokenエンドポイントへPOST
$ch = curl_init($token_endpoint);
curl_setopt( $ch, CURLOPT_SSL_VERIFYPEER, false);
curl_setopt( $ch, CURLOPT_POSTFIELDS, http_build_query($postdata));
curl_setopt( $ch, CURLOPT_RETURNTRANSFER, true );
$response = json_decode(curl_exec($ch));
curl_close($ch);

// id_tokenの取り出しとdecode
$id_token = explode('.', $response->id_token);
$payload = base64_decode(str_pad(strtr($id_token[1], '-_', '+/'), strlen($id_token[1]) % 4, '=', STR_PAD_RIGHT));
$payload_json = json_decode($payload, true);

// 整形と表示
print<<<EOF
    <html>
    <head>
    <meta http-equiv='Content-Type' content='text/html; charset=utf-8' />
    <title>Obtained claims</title>
    </head>
    <body>
    <table border=1>
    <tr><th>Claim</th><th>Value</th></tr>
EOF;
    foreach($payload_json as $key => $value){
        if($key == "emails"){
            foreach($value as $mail_key => $mail_value){
                print('<tr><td>'.$key.'</td><td>'.$mail_value.'</td></tr>');                    
            }
        }else{
            print('<tr><td>'.$key.'</td><td>'.$value.'</td></tr>');            
        }
    }
print<<<EOF
    </table>
    </body>
    </html>
EOF;

?>

2013年12月31日火曜日

[OAuth]年末大掃除。Facebookへのアクセス許可の整理

番外編です。
年末なので色々とPC環境やFacebook等の設定の整理をしています。

Facebookを使っていると、色々なアプリケーションやWebサイトに「いいね!」をしたり、プロフィール情報の読み取りや投稿許可を与えたりしてしまう(せざるを得ない)事があると思います。(この辺りがOAuthです)

あんまりアクセス許可を与えっぱなしにしておくのも気持ちが悪いのでいい機会なのでまとめて整理をしてしまいましょう。

まずは、「いいね!」をしてしまったWebサイトやFacebookページの整理です。

自分のプロフィールのアクティビティを開きます。

左下に「ページと趣味、関心」があるので、開きます。

色々なページに「いいね!」をしているのがわかります。
「いいね!」を取り消すにはそれぞれにある鉛筆マークをクリックします。
※実際にJICSのサイトの「いいね!」を消したらダメですよ(これ重要)



次に、アプリに与えてしまった許可の整理です。

こちらはプライバシー設定の中にあります。
画面右上のメニューからプライバシー設定を開きます。


続いてプライバシー設定画面の左下のアプリを開きます。

すると許可を与えたアプリの一覧が表示されます。
結構な数のアプリを使ってます。


ここで編集をクリックすると具体的にどんな許可を与えているのかをみることができます。

Amazonアプリ、結構な権限を要求してきています。。。。
ここで不要だと思ったら×をクリックして権限ごとに削除してしまうのも良いですし、アプリケーション単位で許可を取り消してしまうこともできます。

でも、消す前に具体的にアプリがいつ、何をしたのか?について見たければ、最終アクセスの中の「詳細を見る」をクリックすると履歴が見れます。

ちょこちょこ覗かれてますね。

信頼できるアプリやページであればいいですが、間違って許可を与えてしまった場合などはこの辺りで適切に管理をしてあげましょう。



と、いうことで年末の大掃除の一環でFacebookの権限周りを整理してみました。
皆さんもこの機会にぜひ大掃除をして良い年をお迎えください。

今年もお世話になりました。