This question might be considered as "too broad" or "good practice", but I guess there might be some pieces of RFC that could answer it.
I am currently developping my OIDC server and I am facing a situation I am not sure how to deal with.
A user has been doing a regular authorization_code flow with a web application. In the end the web application has a valid ID token. Now for some reasons the web application forget this token soon after, and the user is running the authentication flow once more:
Should the OP serve the previous ID token, as it is still valid? Or are there some security issues here?
If not, should the OP ask again for the user consent, or consider it already has it?
I think you can find your answer here: https://openid.net/specs/openid-connect-core-1_0.html#Authenticates. Also take note on the wording here: https://openid.net/specs/openid-connect-core-1_0.html#TokenResponse, saying "ID Token value associated with the authenticated session".
My interpretation is: The ID token can be seen associated to an authenticated session that the OP might have, depending on the implementation. So yes, the OP is allowed to serve the same ID token, unless the prompt parameter of the Authentication Request requires reauthentication or consent.
If the Client always wants/needs explicit authentication and/or consent, the prompt parameter can be used for that purpose.
Related
I have built a Web API and now I am trying to determine the best approach to secure it.
I would like to use tokens along with credentials and thus, once the user is validated, on future requests a token can be passed with the http request. This API will always be called by one particular account and the username/password will always remain the same.
I am working with an already existing site backend, which has its own login implemented and stores user data. So I would like to stay away from creating new database tables to store user records. For that reason, I think implementing .Net Identity is maybe a overkill.
One of the options I am thinking of is grabbing the credentials from the http request and attempting the SQL connection with it. If the connection passes, then the user is legit. If it does not, it means I have to return access denied. Is this a good way of going about it? If yes, what can I use for token generation and validation?
Check out this guide which is specific for Oauth tokens with .NET:
OAuth with JSON Web Tokens In .NET
Also, make sure to follow the guideliness, because tokens must expire and be renewed after a while, for security reasons. You shoudn't use a permanent token, of course.
It's a know problem that Instant Flow struggles from confused problem, so you have to check whether access_token you received was given to your application.
I always considered it's not a problem for Authorization Code flow but in this answer it was mentioned it is not so and you have to verify token even in Authorization Token flow.
But honestly I can't figure out a workflow where it's necessary. Like we receive a code and then make direct request for a token (specifying client_secret). I don't understand how we could be forced to use a wrong token in this flow.
The answer that you refer to talks about an access_token delivered to a Resource Server. That is also in general where the "confused deputy" issue applies.
In your post you refer to the Authorization Code delivered to the Client. That is different and does not suffer from the same confused deputy attack as described.
It should be noted though that the Authorization Code grant type may be vulnerable to a related attack ("Authorization Server Mixup") if the Client talks to multiple Authorization Servers (AS) somewhat for the same reason: the Client is not able to detect if the Authorization Code is actually issued by the AS that it thinks it talks to. Registering a Redirect URI that is specific for each AS addresses this.
I've been reading a fair bit on Microservices recently, and especially around AuthN and AuthZ. For the most part, this all makes a lot of sense, and I can see how it all should work.
For what I'm playing with, I going with delegated authorization - so I'm to be passing tokens around from client to service, and then passing the same token on from service to service. I also have an endpoint on the OAuth2 Service that will accept a token and return the details of the token - the User ID, the Start and End of the validity period, the scopes that the token is valid for, etc.
The problem that I'm running into here is - in order to correctly issue a token, there needs to be some communication with the User Service to ensure that the User that the token is for is actually valid. And in order to verify a Token, there needs to be some communication with the User Service to ensure that the User is still valid. And yet, in order to safely communicate with the User Service to get details about a User, a Token is needed that gives permission for this access.
I assume there is some standard practice on how to solve this circular dependency between the OAuth2 and User Service, but I've not seen any mention of it at all. Is this a common problem? Or have I just missed something obvious?
(Note - for now I'm only implementing Client Credentials Grant and Resource Owner Password Credentials Grant, since I'm only playing around to see how it all works and they're easier to call with cURL. I don't know that this makes any difference though)
Yeah, that's a bit of a chicken and egg problem. Not sure how much control you have over the authorization server, but one way of solving this issue is to secure the call to the user info service using client certificates.
Another is to combine the user info service and authorization server into one service and eliminate the need for the call all together.
I was recently asked the difference between frontend user authetication and backend user authentication ( during an interview ). I could not come up with an answer to his question. He asked me if the authentication you see on the web all the time is done at frontend or backend, I answered backend. Then he asked what is frontend authetication then, I could not answer.
I googled to find out, but could not get exact difference between the two, what is done at frontend vs what is done at backend. How, where and why each of them are used?
Any help would be appreciated.
EDIT : I read something related Here. It talks about something called dual authentication. Still, I am not able to understand the concept of frontend authentication.
My understanding is that after a user is authenticated on the backend, a unique cookie is issued to the browser. This might be considered frontend authentication, as it allows users to continue using a site without having to log in to every single page. The website recognizes the user from the cookie data for each subsequent call, subject to whatever limitations are put in place.
A simple example would be a cookie that stores the username and password, but obviously that wouldn't be very secure. More sophisticated methods would involve encryption, SSL, various flags (secure, http-only, expiry-date), and so on.
The question is subjective and can have too many interpretations based on context.There's a type of user to system authentication and system to system authentication. The closest analogy of front end authentication in this case will be user to system authentication irrespective of the underlying protocol and whether or not an explicit back end stack being used. Whenever two systems have to authenticate against each other without a user involved can be analogous to Backend Authentication. Again this is subjective and very contextual
Can I use the request token given by the OAuth provider and use it forever? I am looking to build a service which interacts with the Delicious api and looks for updated bookmarks every fortnight. I was just wondering if I could use the same request token instead of asking the user to authenticate again and again. If I cannot, which is what I guess the answer will be, what would be a best practice for such an action?
My last option would be to expect users to give up their delicious username and passwords to me, in which case, my job becomes extremely easy.
This is implementation-specific - you'll have to see what the Delicious docs say about the token. It may expire, have limited uses, or have side effects when used.
Most OAuth implementations will probably expire their tokens at some point to reduce the number of valid tokens they have to keep track of.
In general, user-agent help should make this less of an issue for SSO authentication systems - when the user shows up without a valid token, the browser is redirected to the authenticator, which looks at stored credentials on the browser (usually cookies) and redirects the user back with a new token, without any user interaction. This can be more complex for OAuth than for OpenID, since it might not be appropriate to issue a new token if it does more than authenticate. And since the authentication/authorization process is implementation specific, you need to be able to enter new credentials unless you know that the token will be valid.
probably not answering your questions directly, twitter oAuth allows to have a permanent request token.