同事说：正常情况下登录接口不返回用户信息，是这样吗

[lowett]

登录只是为了拿 token ，成功后要调用用户信息接口。

经历过的项目都有返回用户信息，可能个人经历有局限，问下大家是怎样的

[craiet]

是的

[EEEEx]

返回啊, 然后也有用户信息接口

[MossFox]

网页应用吗，如果 token 是存在本地的，登陆拿到 token 之后调用请求用户信息的接口可以确保 token 是被正确保存了的。
如果使用的是 Cookie 存储 token ，在跨域 iframe 里面设置 Cookie 会失败。如果用其他方式的存储，用户如果禁用了 Cookie ，基本上所有 Storage API 都会在访问时抛出异常（包括 localStorage ）。这些情况都算是，登陆请求成功但是 token 没有办法被保存的情境。

我见过的大约只有上面这种了，楼下补充看看。

[chinagxwei]

登录只返回登录账户信息，用户信息要单独获取

[k9982874]

这玩意哪有什么规范，看情况，看心情。他就是懒。

[thinkershare]

看心情，也可也经用户基本信息放置到 token 里面，不过用户的 profile, 一般都是调用独立接口去获取到，比较认证和用户信息没那么强的关联性，特别实在 OAuth2 这种授权体系下。

[lowett]

项目是 app ，token 在 user 里面

[lambdaq]

> 正常情况下登录接口不返回用户信息

很符合 RESTful 原教旨份子 给我的刻板印象。

[opengps]

这种设计没什么规定，因为用 token 可以去拿所有授权内的信息。
可能为了方便，会多返回一个用户信息的 id 使用

[AoEiuV020JP]

有点坑，我们是登录返回一部分，但不够，还得调用户信息接口，

[ysy950803]

他想摸鱼，不想做，没什么所谓的规范和铁律。
而且其实很多后端和前端的交互逼事儿，不是他写就是你写，后端写灵活性更大，反正就那么些接口调来调去。

[MeteorCat]

玩家详情单独接口（用户详情记录大量最后充值时间最后充值金额小游戏签到这种，实际上登陆不需要这些），登陆只返回上次登陆时间 IP 简单信息

[Tink]

这不是看需求吗

[vikaptain]

我一般会顺带返回一些基本信息，像用户名，姓名这些。其他的更详细的信息就走详情接口

[yidinghe]

考虑到登录授权和用户信息属于不同的服务，请求两次是方便后端服务进行重构治理的，否则的话就等于是强行要求登录授权服务绑定用户信息服务。

[neptuno]

大厂是这样的，小厂，就那么几个接口，登陆直接能返回，为啥还要再调用一次。

[sjn9588]

那打开 app 自动登录场景下，难道用来记住用户密码来做嘛？

[MeteorCat]

登陆接口越简单越好，游戏公司接口有选服概念，登陆之后选服创建角色这种情况，所以详情接口独立出来是很正常的事，具体这种并不是什么错误做法也不存在懒不懒的问题

[chenPiMeiHaoChi]

硬要这么说也没啥问题，因为有的可能是登录去的鉴权服务，获取用户信息去的用户服务。鉴权服务里根据业务系统不同有自己的逻辑，可能再去调其他第三方/子系统的登录。

[cheng6563]

挺正常的，账号和用户信息可能并不是绑定的，你登录的这个账号可能可以用于多个后台系统，这时在登录时就不适合返回用户信息。

[dqzcwxb]

他是不是 get 获取资源,delete 删除资源

[ciki]

看场景吧，大多数情况都是值返回 token 。如果你这个场景需要用户信息，直接返回能省很多事那也不是不可以

[liuidetmks]

碰到这样同事，难搞哦，顺手的事情都不愿意支持

[cctvabu]

这都是看业务了，不过如果非要说的话我支持分离获取

[gniviliving]

登录警察虽迟但到
登录警察统计：
使用登录：7 人
使用登陆：4 人

[wu00]

一般不返回，要获取用户信息单独请求；
token 里面最多带上用户静态信息比如 id ，其它动态信息随时会改

[SACKJJKLL]

可以返回用户脱敏信息,主要不能有密码,或者采取 token 存用户 id 然后二次查询用户脱敏信息,看业务需求

[8355]

auth 服务通常只会返回基本信息，够客户端做一般初始化操作，小应用同表一起返回也可以，大应用一般是区分接口返回的，

[unco020511]

一般是不返回的

[superchijinpeng]

不返回啊

[abear]

一般是不返回的，没有 getUserInfo 的接口都是魔鬼。每次刷新都不知道当前用户是谁

[broken123]

是的，正常来说 app 端只会返回 token ，在 heade 里面，然后去获取 userInfo 信息。从后段微服务架构来说就是这样的设计的。 但是其实也可以聚合的。也不是绝对的，他那边可以多写一个接口聚合，如果有现成的接口 你直接几下写了就完事。也不复杂。些许小事罢了。我现在就是 你咋个设计我就咋个写 不愿意争论这些了。客户端就一个人 很难犟得过后端几个人。

[broken123]

反正都能做 ，无所谓了。懒得麻烦。

[brader]

这个其实都行，看后端心情，前端有什么用什么就行了。
因为用户信息这个接口，复用率非常高，有些后端会觉得提供了专门接口了，就不会在附加返回这个信息给前端了，这种流派的后端一般比较坚持模块化、接口单一性。
但是往往很多前端比较喜欢的是面向页面提供接口，希望后端一个接口就把当前页面需要的数据全部返回来。

[oppoic]

我们是这样的：登录只返回成功，不返回 token 这个字符串，token 由后端在账号密码校验之后写到当前域的 cookie 里（开发、测试、线上的域名和 cookie 键是不同的，后端配置后端写）

前端拿到登录接口的 ok 返回，就直接跳转首页开始调接口，同时也不用前端手动把 token 携带到 header 里之类的，http 请求会自动携带当前域的 cookie ，后端根据配置的 cookie 键取，然后校验

最终流程是这样：用户访问首页，前端不判断是否有 cookie （前端不关心任何登录状态，由后端判断），直接调 UserInfo 接口，后端发现没有 cookie 返回特定 code ，前端跳转登录页

用 cookie 的好处是：最简单最原生的方案实现多个二级域名站点的单点登录

[me1onsoda]

不给用户信息也是有充分理由，单一原则。登录就是登录

[rm0gang0rf]

选择困难症初期患者

[lzgshsj]

一般这种时候就是前端去搞 BFF 的契机了

[lujiaxing]

不一定.
图方便的话登录之后给返回用户信息没毛病.

但是如果按照接口职责单一原则, 用户信息接口单独获取也无可厚非.

[masterclock]

登录实体未必是用户，未必关联了用户，未必有权限获取用户信息
登录服务器未必有用户的信息

[cnoder]

你们除了登录接口会不会还有地方要获取用户信息，如果有，那就最好单独加个接口，不然两个接口返回一些结构一致的信息也是冗余。

[kingjpa]

都合理，各有各的考虑

[flyqie]

看心情。

但个人不会登陆接口返回用户信息。

[QlanQ]

不返回，因为我必须要给前端一个获取用户信息的接口
你也不想，前端获取用户信息的来源有两个吧，这样不是更麻烦？

[987N]

没错啊，登录只返 Token ，用 token 再去拿用户信息

[ShuWei]

你们打一架，谁赢了听谁的，相信我，配合愉快才是最重要的，没有那么多所谓的规矩和经验要遵守

[zoharSoul]

是的, 这都不是一个服务, 甚至可能不是一个组的, 怎么返回?

[lowett]

@ShuWei 没有这么严重，就了解下这方面的情况。 我公司是都放会的，就这个人不返回

[Goooooos]

如果对方说不出两者优缺点，一律不用理会

[darklost]

可以登录套一层 GraphQL 解决一切 /狗头

[pkoukk]

不返回，谁知道你登录之后要干啥业务，不同的业务领域可能有各自的数据，还不是得再拉一遍

[jsq2627]

按照 OAuth 2.0/OIDC 的精神，登录过程就是从 token endpoint 获取 id token ，并不返回用户信息

[jsq2627]

@jsq2627 但是 id token 通常是个 JWT ，为了方便可能也会塞一些不变的用户信息，比如 email

[buffzty]

登陆接口必须返回个人信息,不然就多了一个串行流程.他就是懒和菜
设计得好的代码 直接调个方法加个字段就行了,他那个估计得再写一遍逻辑 他肯定懒得写, 菜是原罪

[securityCoding]

不返回

[IvanLi127]

登录原则上不返回用户信息，这对前后端都省事。前端正常都是先请求用户信息，401 后才跳登录，登录完回去重新走原来逻辑就完事了。后端也是，登录接口完全不用处理要返回什么信息，干干净净，后面改接口也不会因为这个漏改。

[utodea]

@lowett 有点好奇什么场景需要在登录接口返回用户信息？还是单纯只是不想多请求一个接口而已？

[looveh]

我们公司就是这样的，登录只返回 token ，然后用 token 请求用户信息