Hot answers tagged

83

OpenID connect will give you an access token plus an id token. The id token is a JWT and contains information about the authenticated user. It is signed by the identity provider and can be read and verified without accessing the identity provider. In addition, OpenID connect standardizes quite a couple things that oauth2 leaves up to choice. for instance ...


37

SAML and OAuth 2 are protocols used in authentication/authorization. JSON Web Tokens (JWT) is a specification for a token that can be used in many applications or protocols - it happens that the OpenID Connect (OIDC) protocol uses the JWT. SAML also defines its own token: SAML Assertion; as does OAuth 2: Access Token. Tokens used by these protocols denote ...


30

OAuth provides only and should only provides authorization using an access token. OpenID connect is built on OAuth 2 in order to provide user authentication information. However, it will not provide you a more robust implementation than OAuth (since it uses OAuth and add some extra interactions with a OpenID provider). OpenID Connect 1.0 is a simple ...


29

My question is what prevents users from intercepting their regular post form the app (getting the token) and then possibly sending bunch of POST requests (using something like postman or fiddler) to create a large number of fake posts or articles or whatever else the app does. Nothing Does the fact that the traffic to the service will eventually go via ...


28

The reason PKCE is important is that on mobile OS, the OS allows apps to register to handle redirect URIs so a malicious app can register and receive redirects with the authorization code for legitimate apps. This is known as an Authorization Code Interception Attack. Authorization Code Interception Attack This is described by WSO2 here: Since multiple ...


24

@catanman makes excellent points regarding the technical considerations around PKCE in SPAs, however just recently the IETF Oauth working group has published a best current practice document (December 28, 2018) stating: Note: although PKCE so far was recommended as a mechanism to protect native apps, this advice applies to all kinds of OAuth ...


24

While all the other answers are correct, the latest OAuth 2.0 for Browser-Based Apps Best Practices Doc (January 29, 2019) states that (emphasis mine): Overview For authorizing users within a browser-based application, the best current practice is to o Use the OAuth 2.0 authorization code flow with the PKCE extension ... As well ...


18

tl;dr Most security issues are with implementation and not protocol, the simpler the better. SAML/WS-Federation and OpenID Connect all use cryptographically signed tokens that support optional encryption SAML/WS-Fed is XML based and takes on the XML threat model while OpenID Connect is JSON based {} and takes on the OAuth2 threat model OpenID Connect ...


17

OAuth is an authorisation protocol, providing a way to give authorisation to access a protected resource. A by-product of the authorisation process is that the user is authenticated. Technically, OAuth does not have to give you any information about the user. What it provides is a validation that the user has given authority to the application to access ...


17

SPAs would not benefit from PKCE. PKCE solves a different problem than the one you're describing. First of all, for SPAs the current best practice is still to use the implicit flow, not the authorization code flow. With the implicit flow, the access token is included in the hash fragment (#) of the redirect URI instead of in a query component (?). Since the ...


16

This write-up Okta has on this subject explains this pretty well IMHO. I believe it's because PKCE is intended for native applications (e.g. Android, iOS, UWP, Electron, etc.) where you leave the security context of your application and go to the browser to authenticate, and rely on the secure return to your application from the browser. You don't ...


12

My question is what prevents users from intercepting their regular post form the app Nothing. Does the fact that the traffic to the service will eventually go via TLS make this a non-issue? If you make it for an mobile platform (Android/iOS), that makes it much harder (but not impossible). If you make it for the browser, this doesn't add much ...


11

API keys are public, by intent. They are an authorisation mechanism, not an authentication mechanism (this is mentioned in your links). It does not matter how they are generated but it matters how they are handled. In other words: "anyone with this key can enter". So, you use API keys when you want to authorise and do not need to authenticate. You use ...


10

To answer your initial question: you do not need to implement CSRF counter-measures on your resource server, if you are not using cookies (sessions) and you are not using basic authentication within the browser. Cookies and the Basic authorization header are stored by the browser for every domain name you visit, and every time you send a request to a site, ...


8

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 ...


7

I'm not sure about OpenID, but for OAuth there is no CORS involved for the actual authentication part, though it may be required on the resource server depending on the type of client that is connecting. In RFC 6749, which defines the OAuth 2 framework, there are four different methods defined for the application to gain authorization (here, client means ...


7

This is an interesting topic and there are a couple of things to consider. First we need to come at it from the API provider, not just the consumer. Who? The main consideration is Authentication vs. “Identity” and Permissions. Refresher: Identity = Who say you are Authentication = Who you really are Permissions = What you can do Check out this post ...


7

The state is given back by the OAuth2 server in the redirected url, so the client app can verify that the request to open the authorization page was indeed triggered by itself. The code_challenge is not given back by the OAuth2 server, but the client app must send the belonging code_verifier with the next request to exchange the authorization code for a ...


6

Here are some ways I can think of but if someone tried hard enough I don't think there would be a way to stop him. Check a fake email - Google's login will only display a password input if the username exists so by entering any email you know does not exists (Ex: ajksjdlalsjdlkasldkldjalk@gmail.com) if the password box still shows up then it is not a ...


6

maybe this is to increase the security in case someone gets unauthorized access to the client app's symmetric secret. That's one valid reason, yes. Sending around short-lived access tokens instead of long-lived shared secrets reduces the attack surface. Is there any other reason? OAuth defines several roles. Often a resource doesn't reside on the same ...


6

I think the intent of OAuth scopes was to provide a framework for delegated consent, which is a form of discretionary authorization, but different from policy-driven authorization, which is what it sounds like you are trying to accomplish. The resource server has the responsibility to enforce both the delegation and the policy-driven approach. Scopes wind ...


6

My question is what prevents users from intercepting their regular post from the app (getting the token) and then possibly sending bunch of POST requests (using something like postman or fiddler) to create a large number of fake posts or articles or whatever else the app does. What are some possible ways from protecting from this? You don't. That is, you ...


6

Your question is a pretty good one and as an IAM practitioner I can only apologize for the confusion. IAM is indeed a large field. I think it may be worthwhile taking a step back and going through the basic elements. Intro IAM or Identity & Access Management is a field of IT Security (just like network security, crypto, etc...). It can be broken down ...


6

Martin's answer has good info and steps to prevent further potential risk. Concerning the authtoken it’s pretty straight forward. For example, when you use your Google account to login to a site, using the following button : Google generates a token using what's called the OAuth 2.0 protocol, allowing this website to login via Google without them ever ...


5

Using OAuth as an authentication method is not recommended, it is explicitly designed as a delegated authorisation method. Facebook was using OAuth as an authentication method, but an enterprising person discovered how to steal the access_token from Facebook - full blog entry OpenID Connect makes it much more difficult to steal access tokens through such a ...


5

Your question boils down to why do passwords get sent in clear text over an encrypted channel and are not hashed on the client before submission? The answer is: if the client is compromised to compromise the TLS session, it does not matter - the password is typed in and can be keylogged. Additionally, hashing on the client side just makes the hash value ...


5

How are they limited Using OAuth, you ask for scopes, which are similar to permissions, this means they can only use the credentials for what they ask for, and cannot do things that are out of scope. Some of the scopes do cover multiple things though, for example being able to copy an email means they can also read the email, which is not something that ...


5

So my understanding of why this is allowed is so that the implementation of CORS wouldn't break existing and well understood functionality which was already allowed by browsers. This also means that preflights aren't required for text/plain and multipart/form-data in addition to application/x-www-form-urlencoded These are referred to as "simple requests" ...


5

Well, you've converted your short-lived access token into a refresh token because you're storing the refresh token in the access token. That pretty much defeats the purpose of using an access token. It's also usually unwise to send the password hash to the client because these things tend to get leaked through bugs or overzealous logging and that makes it ...


5

Is a "magic link" a kind of authentication? Yes, it is. It authenticates the user, similarly to having them type a password, dip a smartcard and enter its PIN, or checking their fingerprint. It is not (inherently) authorization, since "clicking a link on an e-mail" doesn't necessarily attest anything. How safe it is to validate only the ...


Only top voted, non community-wiki answers of a minimum length are eligible