Create an OAuth compatible SSO: troubles with client
I want to create Google-like single sign on application to allow members of one of our application reach all other apps without the need of signing-in again.
But I can't find the right way to do it, I think I'm missing something with the grant_type=authorization_code method, and especially this part of the RFC 6749:
(B) The authorization server authenticates the resource owner (via the user-agent) and establishes whether the resource owner grants or denies the client's access request.
SSO app is itself an OAuth client with its own client_id, so when user authenticates, SSO gets an access_token for the couple (SSO, user) and stores it to SSO's session for further uses.
So when a client (the "app") will need an access_token, it will be redirected to SSO, that will itself request an authorization_code with the app's client_id and my SSO's access_token in the Authorization header to know which user want to access the resource.
And here is the problem: my SSO's access_token was created for the SSO's client_id and not the app's client_id. So it seems hacky / invalid to use an access_token generated for one client to identify the user that grants another client access to some resources.
Here is a (simplified) schema for a better comprehension of the flow:
01 User Client SSO OAuth Server 01
02 + + + + 02
03 | | | | 03
04 | User requests resource | | | 04
05 | +-------------------------> | | | 05
06 | | | | 06
07 | | Client redirects to SSO | | 07
08 | | +-----------------------> | | 08
09 | | | | 09
10 | | | SSO authenticates user | 10
11 | | | +------------------------> | 11
12 | | | | 12
13 | | | token stored on SSO side | 13
14 | | | <------------------------+ | 14
15 | | | | 15
16 | | | SSO requests grant code | 16
17 | | | +------------------------> | 17
18 | | | | 18
19 | | authorization code returned to client | 19
20 | | <----------------------------------------------------+ | 20
21 | | | | 21
22 | | authorization code exchanged for an access_token | 22
23 | | +----------------------------------------------------> | 23
24 | | | | 24
25 | | access_token returned to client | 25
26 | | <---------------------------------------------------+ | 26
27 | | | | 27
28 | user can access resource | | | 28
29 | <-------------------------+ | | | 29
30 + + + + 30
On line 10, we assume user is not signed-in, so user enters its credentials on the SSO UI, and SSO will then call the authorization server with its own client_id and a grant_type=password to get an access_token.
On line 13, access_token is given to SSO, it's an access_token that binds user_id with the SSO's client_id, this way we signed-in user in a centralized application, and we don't need to sign-in him anymore.
On line 16, once user clicked on "authorize" to grant client access resources, SSO requests an authorization code to the OAuth server on the behalf of the user with the SSO's access_token in the authorization header to identify that user.
In my flow, SSO access_token identifies a user for other clients, and I think it's invalid. Can someone give me some advices?
In a regular setup like this, there would be no SSO app in between Client and Authorization Server but the Clients would directly integrate into the Authorization Server with standard OAuth 2.0 and the Authorization Server would integrate with some SSO application to authenticate the user.
"some SSO application" could be something that you've developed yourself or an external provider that speaks a standardized SSO protocol like SAML or OpenID Connect, eg Google or Microsoft.
链接地址: http://www.djcxy.com/p/47976.html上一篇: 使用CAS登录跨SSO协议的持久性