Single sign on based on OAuth2

Question

I develop SSO system based on OAuth2.

I have 3 services:

1. SSO identity provider which contains Users and OAuth2 server - http://sso.idp.loc

2. SSO service provider with front-end part on Angular - http://sso.sp-angular.loc

3. SSO service provider (casual website) - http://sso.sp-web.loc

Service providers check every request access token issued by identity provider.

Mechanism is next:

1. Go to any serivce provider and press login
2. Redirect to sso.idp.loc/login_check to check credentials (from cookies).
3. If not authorized - go to sso.idp.loc/login.
4. After logging in - set cookies for identity provider and redirect to target service provider with these cookies in get parameter.
5. Set new cookies from get parameter for service provider and redirect to target path.
6. If suddenly authentification is failed on service provider - go to sso.idp.loc/login_check with target path.

Cookies contain oauth access and tokens.

Everyting is fine while access token is valid. Once access token expires service prodider goes to sso.idp.loc/login_check and checks again access token and then tries to get new once using refresh token. If success then new creadentials is set to sso.idp.loc and service provider. Let's say is happened on sso.sp-web.loc.

Here I have several problems:

1. Then another service provider sso.sp-angular.loc does not know that credentials are changed and next request will redirect to sso.idp.loc/login_check (it can be sorted out by sending request second time).
2. When user is editing form on sso.sp-web.loc and token has become expired then submit will fail.
3. How to manage ajax calls when token expired?

Should be consideried a fact that access token can be changed at any time.

Probably something is wrong in my system. I will be glad to here any solutions.

Answer 1

I think you SSO concept is flawed - you should not be sharing the same tokens. Tokens should be different for each client (application). OAuth2 SSO is usually implemented in the following way (the implementation is not covered by the OAuth2 RFC):

1. Application "App1" requests a token by redirecting a user's browser to an authorization server (/auth endpoint).
2. The authorization server sets a session cookie to the browser and keeps info about which user was authenticated in that session. The cookie is valid only for the authorization server requests.
3. When another application "App2" requests a token, the browser sends the session cookie along with the /auth endpoint request. The authorization server resolves the session. The session was already authenticated so the authorization server may decide not to ask for credentials and release new tokens (or an auth code) right away.

Answer 2

You seem to have implemented the Implicit grant type of OAuth 2.0. That's pretty insecured. Ideally you should implement Authorization Code grant type and maintain your client secrets on the resource server (which you are referring to as service provider) side. I recommend you read the answers here and here.

Now let's answer the queries:

1. If you set your domain attribute of your cookie correctly, the cookie set by the first resource server should also be available to the second server.

2. When user is editing a form and token expires, the api filter in resource server can detect the expired token and return 401 response code to client. On receiving 401, client or browser can make another api call in the server to renew access token. The api will fetch the refresh token from cookie and make a call to the authorization server with client secret and refresh token to get a new access token. If the refresh tiken is not expired, authorization server would return a new pair of access and refresh token which will be returned to the browser and cookies set. The browser will now call the form submit api again with new access token. All these will happen seamlessly to the user. Total failure will happen only if the refresh token gets expired.

3. Same way as mentioned in 2.