3 ms·

> token becomes too powerful and can be made to call any service. If UA token is passed as is down the chain of microservices, then every service starts to acc

> token becomes too powerful and can be made to call any service. If UA token is passed as is down the chain of microservices, then every service starts to accept it. Intercepting this single token allows attacked to craws whole internal system. It wont grant access to other users data, but nevertheless it doesn't seem like a secure solution to me. > Each sub-service can have in token what is required to access it, and that can be managed by main frontend service. This would require UA token to contain audience claim of every single internal service, this is unlikely to pass security review.

lukevp 6y ago
If the token having claims is a security issue, the entry point could swap the users token (containing just their unique id and an expiration) with an authorized token with claims, and keep that token within the local network. Then there’s a single token broker layer and claims are secure. I’m not sure why claims would be an issue to have in the original token though, could you provide some more info on that?
majkinetor 6y ago
> Intercepting this single token allows attacked to craws whole internal system. It can intercept it, but can not change it. It can replay it eventually (even that shortly, depending on timeframe of your access token which is usually minutes) but you can protect against it. > This would require UA token to contain audience claim of every single internal service, this is unlikely to pass security review. I have penetration tests on my main service. Sub-services are not accessible and can be secured to desired level on the internal network. I never had security inspections on internal services (I work on highly critical gov systems). Maybe in some domains its like you say but I believe its generally not a problem. Furthermore, we need to have some perspective on this - there are multiple easier ways to hack a service and there probably exists big number of other exploits that are easier to achieve.

lukevp 6y ago

If the token having claims is a security issue, the entry point could swap the users token (containing just their unique id and an expiration) with an authorized token with claims, and keep that token within the local network. Then there’s a single token broker layer and claims are secure. I’m not sure why claims would be an issue to have in the original token though, could you provide some more info on that?

majkinetor 6y ago

> Intercepting this single token allows attacked to craws whole internal system. It can intercept it, but can not change it. It can replay it eventually (even that shortly, depending on timeframe of your access token which is usually minutes) but you can protect against it. > This would require UA token to contain audience claim of every single internal service, this is unlikely to pass security review. I have penetration tests on my main service. Sub-services are not accessible and can be secured to desired level on the internal network. I never had security inspections on internal services (I work on highly critical gov systems). Maybe in some domains its like you say but I believe its generally not a problem. Furthermore, we need to have some perspective on this - there are multiple easier ways to hack a service and there probably exists big number of other exploits that are easier to achieve.