New answers tagged

0

The only requirement that directly relates to session management is 6.5.10 which is very general: 6.5.10 Broken authentication and session management. Secure authentication and session management prevents unauthorized individuals from compromising legitimate account credentials, keys, or session tokens that would otherwise enable the intruder to ...


0

In the OWASP's implementation example, they store the user context in a Secure, HttpOnly, Samesite cookie. This helps to prevent attacker from using XSS to read this Cookie value.


2

They use a concept sometimes called "Universal Links" or "App links". Here's an example of how those are implemented in Windows: https://docs.microsoft.com/en-us/windows/uwp/launch-resume/web-to-app-linking and here's one for iOS apps: https://developer.apple.com/ios/universal-links/ The idea is that these are HTTPS URLs that can be mapped to particular ...


0

Adding more accurate answer based on the discussion above. Based on your clarification in the comments the flow is to try to download a resource through the SPA, after sign in. Then the appropriate course of action is to change the third party service to verify the access token that SPA will send to it, on behalf of the user. This way SPA will not know and ...


0

First and foremost the OAuth protocol is used for delegated authorization. To support authentication you need to do a bit more on top of OAuth2. Having said that, the problem you have described is a SSO(Single Sign On) problem. There are different protocols to achieve this. The most popular one right now is OpenIdConnect. Have a look at the docs of the ...


1

From my experience, it is always recommended to have all identity-based operations in one place. In your use case it is AuthN service which manages the identity. I would also adice to taking a look into biggest gamers on this market: Google Account, MS Azure AD, GitHub, Twitter. If you have application which uses those identity providers to authenticate ...


0

I believe there is nothing fundamentally wrong with the way you are implementing the forgotten password functionality. The process however needs to be implemented securely, or otherwise that link alone could be used to hijack accounts once or more than once: Does the forgotten password link work more than once?; It shouldn't so it can't be reused later; ...


0

I suppose that this artictle should explain the most of your doubts. https://medium.com/securing/what-is-going-on-with-oauth-2-0-and-why-you-should-not-use-it-for-authentication-5f47597b2611 Shortly speaking if you use implicit flow you are vulnerable to token leakage through URL (because URLs are logged into HTTP server logs) or token injection (where ...


1

Bit of basics: Authorization: (Check if user A has access to resource Z). Authentication: check if the user who claims being A is really A. OAuth2 is not an authentication protocol From the oauth.net site: The OAuth 2.0 specification defines a delegation protocol that is useful for conveying authorization decisions across a network of web-enabled ...


0

Where is the client id stored depends on the architecture of your web application. OAuth 2 defines two client types - public client (which cannot keep client credentials secret) and a confidential client (which can keep client credentials secret). In any case, the client id is not a secret. This is what OAuth specification says about the client id: The ...


Top 50 recent answers are included