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

[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]

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