The Stack Overflow podcast is back! Listen to an interview with our new CEO.

New answers tagged

0

Implicit Flow is now discouraged in favour of Code Flow with PKCE. This is a fairly recent change (in the last year or so), which is why you might see quite a lot of documentation and libraries still recommending Implicit Flow, and support for Code Flow with PKCE is sometimes still lacking in OIDC libraries. The main concern with Implicit Flow is that at ...


0

It boils down to whether there is a chance your authorization code might leak. PKCE is about preventing leaked "authorization code"s from being useful. When you ask for an authorization code, PKCE requires you to send the hash of a nonce. When you redeem the code, you must provide the original nonce. This means that a malicious actor (XSS or CSRF ...


0

This sounds like you are looking for the scope property of oAuth 2. with scope you can ask for different level of access and to different type of access. You could even use scoping to limit access to specific Datacenters, just use a named scope per Datacenter. The oAuth 2 provider can even inform the client about the given scopes, going beyond the scopes ...


0

The correct answer depends on which Google OAuth Token, there are three: Access, Refresh, and Identity. Google Access and identity Tokens are only valid for one hour. This means one hour after creation they are worthless. Google Refresh Tokens do not expire and can be used to recreate the other two. It is very common for "dumb" sites to store the Refresh ...


-1

If you want to identify users on behalf of the access token, you should rather think of OpenID Connect standard. As OAuth2 is an Authorization framework, it is NOT designed for Authentication purposes. There you will be able to use identity tokens which can be retrieved on behalf of request to UserInfo endpoint with access token as Bearer. I have never ...


1

Storing a whitelist of access tokens in a database is a great way to perform access token revocation; if it's not in the DB, don't accept the token. However, this undermines one of the main advantages of JWTs: being able to verify tokens without having to access to a centralised DB. Usually, the short lifespan of access tokens is considered a good enough ...


0

To answer your second question, we can assume that the code exchange (C + D) happens in the back channel (back end to back end) and is safe from any client-side attack. Intercepting the code in a redirect from the auth server to the client is fundamentally easier than intercepting something from between your own client's front end and back end. One way to ...


0

If you consider that the network between the VPN's endpoint and the OAuth2 server is safe (because request are reencrypted, or it's a "trusted network"), then an HTTPS tunnel or a VPN tunnel offers the same level of security (encryption and authentication). However, as stated in section 3.1.2.1 of the OAuth2 RFC: The redirection endpoint SHOULD require ...


1

I can't read, apparently. The justification is described in the RFC itself: A number of pre-conditions need to hold for this attack to work: [...] 4. Either one of the following condition is met: 4a. The attacker (via the installed application) is able to observe only the responses from the authorization endpoint. When "...


0

Most importantly: you can't use a JWT as an API token. There is a very important property that API tokens need that JWTs don't (and can't) have: revokability. This is important for you. You mentioned that you will use the tokens to track usage and limit the number of calls the user can make. If a user has their API token stolen then the attacker can use ...


Top 50 recent answers are included