※ 引述《kiii210 (Johnny.T)》之铭言： : 各位前辈好～想请问一下关於用Facebook账号来登入app的问题～ : 现在很多app已经用这个方法，直接用使用者的Facebook姓名，mail来注册一个账号 : 省去很多填资料的麻烦～ 我不清楚你的app是否会用到facebook的功能(分享文章等)， 我下面的回答是假设你都不会用到除了登入之外的功能。 : 目前公司网站已有做Facebook登入功能， : 用Facebook帐号登入之後，会把姓名，Mail存起来当做一个会员～ : 现在公司app也打算用这个方法，网站跟app的资料要互通～ : 目前想到的做法是这样：http://ppt.cc/-UEt : 1. 点击Facebook登入 : 2. 登入成功，取得access_token : 3. 传回给伺服器，由伺服器处理注册账号的动作 : 疑问： : 1) 这中间是否会有安全性的问题？因为拿到token就等於有帐号的存取权限 : 是否该透过https加密後送出？ fb给的access_token极度建议用https传送回给自己。 不过安全性的问题的话..depends on 你要的权限，若你仅要求最基本的权限(拿fbid)， 基本上不会对使用者的fb造成什麽事情，不过若用一般http传输， 会让骇客有可能用别人的帐号，进入你们的服务。 : 2) 安全性问题2 : 开发网站的同事担心有心人拿到app与伺服器沟通的api网址後会乱搞， : 目前想法：传access_token给伺服器之後，由伺服器拿去与Facebook Graph Api验证 : https://graph.facebook.com/me/?access_token= : 如果回传的verified是true，代表这个使用者没问题，可以放心的做沟通 : 反之拒绝回传资料。(http://ppt.cc/HBEU) : 这样是否可以？ 大致看起来可以，不过再次强调，与你们server的沟通建议用https。 : 3) 该如何保持"登入状态"？ : 开发网站的同事表示不想每次都跟Facebook验证token是否有效， : 那我是不是在跟api做沟通的时候把cookie存在UserDefaults里面， : 待下次跟api做沟通把cookie也一并送出去即可？ : 感谢耐心看完～因为没开发这方面的经验～网路上文章也很少～ : 主要是顾虑安全性问题，不然应该不会有这麽多东西要担心～@@" : 谢谢! 有几个方法，我先假设在你的会员资料库有储存uid和fbid。 uid代表使用者在你们服务中的unique id, fbid就是他在fb的unique id(一个不定长度的字串，如100000123456789) 1. 每次和fb验证该token的fbid是啥，再查你的uid。(如你所说) 2. 一样每次都传fb access_token 回你的server，但是你的server有create一个 token的快取资料表，把access_token和对应的fbid存起来。 3. 第一次和fb取得fbid之後，把这个fbid和你的uid传回app端， 把fbid+uid当成你api第二次之後的验证方式，这个方式有点不大安全，但最简单。 不过骇客除了要先猜出你的api介面，还要有正确的fbid+uid配对。 4. 第一次和fb取得fbid之後，你再查到你的uid之後，自己产生token。 (我觉得这应该是大部份app的做法) 譬如说，一个使用者在你的服务中uid是123， 你产生一个token 202cb962ac59075b964b07152d234b70 (123的md5)， (当然你绝对不会用md5(uid)产生token) 把这个token传回app，存在app的userdefault， 顺便把token/uid pair 存在伺服器资料库， 每次和伺服器要新资料时，就把这个token当认证工具。 在产生token的时候记得考虑，token应该要是unique的。 再次强调，所有过程必用https。 --

※ 发信站: 批踢踢实业坊(ptt.cc) ◆ From: 123.204.86.9 ※ 编辑: benck 来自: 123.204.86.9 (07/09 10:44) ※ 编辑: benck 来自: 123.204.86.9 (07/10 05:55)