3 ms·

Maybe I’m missing something, but what is the advantage of maintaining a separate oauth provider (sso-auth)? Since they apparently need to support just google cr

Maybe I’m missing something, but what is the advantage of maintaining a separate oauth provider (sso-auth)? Since they apparently need to support just google creds, why not let sso-proxy talk to google directly? Why do they need to maintain a separate token infrastructure? The other (related) question is how the token refresh works - is it tied to the underlying refresh token generated by google, or is it something completely independent?

X-Istence 8y ago
sso-auth allows you to authenticate against Google once, and then any other requests that come to it can be redirect back to the calling application without first hitting Google. If you registered each new app directly with Google, every time the user visited a new app, they would be redirect to Google to provide permission to the app to log them in, and then be redirected back. This is described in: https://tech.buzzfeed.com/unleashing-the-a6a1a5da39d6 https://tech.buzzfeed.com/unleashing-the-a6a1a5da39d6
- Lx1oG-AWb6h_ZG0 8y ago
  > Now, their employees can securely access Ghost Land at ghost-land.sso.pacworld.com That’s the part I’m confused about. They force all sites that need SSO to be under the same subdomain. If they can share the same session cookie, why does each microservice need to redirect at all? Can’t they all use the same oauth app underneath?
  - Buge 8y ago
    One possible reason is they might want each microservice to be a separate security domain. So that if one microservice is compromised, attackers cannot use credentials stolen from that microservice to control other microservices.
  - X-Istence 8y ago
    There is no requirement for all of them to be under the same domain. It's not made clear in the article, but the documentation shows how you can run all of them under different domains too.
luckydata 8y ago
I think it's well explained in the article.

X-Istence 8y ago

sso-auth allows you to authenticate against Google once, and then any other requests that come to it can be redirect back to the calling application without first hitting Google. If you registered each new app directly with Google, every time the user visited a new app, they would be redirect to Google to provide permission to the app to log them in, and then be redirected back. This is described in: https://tech.buzzfeed.com/unleashing-the-a6a1a5da39d6 https://tech.buzzfeed.com/unleashing-the-a6a1a5da39d6

Lx1oG-AWb6h_ZG0 8y ago
> Now, their employees can securely access Ghost Land at ghost-land.sso.pacworld.com That’s the part I’m confused about. They force all sites that need SSO to be under the same subdomain. If they can share the same session cookie, why does each microservice need to redirect at all? Can’t they all use the same oauth app underneath?
- Buge 8y ago
  One possible reason is they might want each microservice to be a separate security domain. So that if one microservice is compromised, attackers cannot use credentials stolen from that microservice to control other microservices.
- X-Istence 8y ago
  There is no requirement for all of them to be under the same domain. It's not made clear in the article, but the documentation shows how you can run all of them under different domains too.

luckydata 8y ago

I think it's well explained in the article.