New answers tagged

1

Even though the connection between user agent and servers are secure, the user agent may not be fully protected. Since authorization code flow ensures the user agent is not privy to the tokens, security is improved by reducing exposure of tokens to between servers only.


1

OpenID Connect is a profile of OAuth2... defining an architecture that enables a person to authorize an identity provider to release certain user claims to a client (website / mobile application). OAuth2 offers the Resource Owner Password Credential Grant, which is rightly maligned by IAM experts as "The Devil". A common pattern for OpenID Connect API is ...


1

Short answer is that it is undefined. If you want a library that supports both, ensure it explicitly states it supports both OAuth 2 and OIDC. If you were to draw a Venn diagram, OAuth 2 and OIDC intersect each other but OAuth 2 also defines some flows that OIDC does not extend, and OIDC adds a flow that is not in OAuth 2. OAuth 2 flows: Authorization ...


3

Is there any reason to not do this? Yes, I think of two reasons not to do it: The user may mistakenly enter in their full-access password into a compromised machine. Once a user enters their lower-access password into a compromised machine, now the attacker potentially knows a username and can try to brute-force the other password. This gives the ...


4

The inherent problem is that the computers are untrusted - multiple passwords going through the same untrusted channel won't really help, and may confuse your clients more than help them. I would strongly suggest adding a second factor authentication via a trusted channel like your client's smart phone. 2FA does not have to be onerous or complicated. Begin ...


3

They may or may not be using token based authorization, and they may or may not be timing out sessions. The reason they never ask you to log in again is entirely separate, and for convenience. Users don't want to log in over and over again, and apps that make them cause them to be unhappy, and being unhappy causes them to give the apps bad ratings, and bad ...


0

The only feasible method for restricting records to specific users is to use authentication. You can use any of the built in identity providers (see https://azure.microsoft.com/en-us/documentation/articles/app-service-mobile-xamarin-ios-get-started-users/ for more information) or you can use a custom authentication scheme (see the sample at https://github....


1

The main issue is making sure that you protect against the confused deputy problem. Imagine you are using OAuth to authenticate users within your application. However, an evil developer has their own application which also uses OAuth. Say their application is a Solitaire game, which uses Google's OAuth API. A user authenticates for Solitaire using their ...


0

You've already mentioned the stateless federated benefits of JWTs, I'm sure those can be agreed on. An attacker doesn't need a user's password to access protected resources, just access to their authentication context. I think one of the risks that you're missing with sever-side tokens, or session based methods, is that those identifiers are also stored on ...



Top 50 recent answers are included