Hot answers tagged

79

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


31

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

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


21

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


17

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


13

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


13

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


13

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


12

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


11

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


10

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


9

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


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

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


6

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


6

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


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

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


5

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


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

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


4

A quick use of a search engine points me as the first hit to stackoverflow: Are Oauth2 client apps required to have SSL connection? which cites the OAuth 2.0 specification which can be summarized with: ... the authorization server MUST require the use of TLS ... The redirection endpoint SHOULD require the use of TLS ... Access token credentials MUST only ...


4

One remark on that: now clients can't deduce what they can do or if their token still active The safest way to store the JWT is probably in a httponly (to prevent XSS) secure cookie (+ take measures against XSRF). If you do that, client-side code can't directly check the JWT anyway. As for your initial question, I guess it can help give more control ...


4

The token you give to the client should contain a signed expiration time that would be verified server-side (e.g., limited to a typical user session time you'd expect for your app). This won't prevent the re-posting, but will limit the period within which it could be done after the authentication. On expiration the user will have to re-authenticate. This is ...


4

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


4

The only thing on Stack Overflow that might not be public forever is a comment. If you edit an answer or question all past versions are still available. Deleted questions and answers are still visible to mods as well as any user with enough rep. Even the chat sites retain permanent public transcripts. It's possible that you could have an admin actually ...


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