而且可以去修改參數(shù)調取別人的資料

防止用戶資料被別人調取，需要做的是驗證調取者的身份，而不是隱藏user_id。

OAuth 本意是用來將接口提供給第三方使用，當然也可以自己用，這個不難學，只要看幾篇文章就會。但是，OAuth 并不能保證足夠的安全，這方面還是要開發(fā)人員自己注意。比如說，在具體的業(yè)務接口設計方面，有幾個原則需要遵守：

1. 參數(shù)最少化。因為 token 就已經能關聯(lián)到用戶的所有信息，所以除此之外不要再有任何與用戶有關的參數(shù)。也就是說，鑒權完成之后，token 就可以幫助隱藏 userid 之類的信息了。token 是臨時性的，比 userid 更安全。
2. 通信加密。與其將某個參數(shù)值進行加密，不如對整個通信進行加密，也就是使用 HTTPS。
3. 用戶隔離。任何一個用戶都不能通過接口返回的信息來推斷任何其他用戶可能的信息。

oauth是用來授權給第三方應用訪問用戶的資源的，如果場景里面沒有第三方，就沒有必要了

一般使用openid不直接使用userId

兩個問題沒關系，OAuth是對第三方應用接入你方web service做身份認證的。采用GUID是防止信息泄漏的。

你采用了OAuth，但是ID是自增的，那么第三方依然可以有意無意的做一些壞事情。

你的問題跟 OAuth 沒關系。

api/getUserInfo?userId=123
這里的問題是，用戶的id是自增的，很容易就被人猜出來有多少用戶，而且可以去修改參數(shù)調取別人的資料。

不管 ID 是什么，也不管別人是否可以猜到 —— 沒有權限看的 id ，就不能看 ，先實現(xiàn)這個“功能”就好了。

你說的是 hashid 吧 composer require elfsundae/laravel-hashid

你這問題和oauth 沒有關系
一般情況下，userid 是在后臺session 中存儲的，前臺url 根本不需要知道，即使需要知道，后臺在用的時候，也是需要進行權限驗證才可以用的。
二般情況下，一個非常low的網站，或者app 后臺沒有session，那么前臺在用的時候 userid 肯定是經過加密的，后臺在用的時候也是要校驗之后再用

前臺只能獲取當前用戶所有信息,后臺也只有有權限的管理員才能看到用戶的信息.一般是不會設計這種接口的.除非是極少數(shù).這個時候一般的會有兩種情況.一種無狀態(tài)的API,一種有狀態(tài)的例如session.
有狀態(tài)的好處理,直接根據(jù)當前的session來獲取當前的用戶,并且查看是否有權限.
無狀態(tài)的,就要根據(jù)你們的規(guī)范來.如果是在header中存的用戶的token,則將用戶token獲取到查詢.如果是通過其他方法,請自行查找.
最基本的套路都是根據(jù)當前用戶是否有權限來獲取.

可以不用 oauth 加密實現(xiàn) 可以參考 JWT