My application is using a RADIUS client implementation in order to authenticate users (using username/password and a shared secret). In the response from the server (Access-Accept), various attributes are provided, and I use them for getting a few relevant user properties.
The problem: once in a while, I need to refresh the value of the "Class" attribute. I don't have the full credentials any more, only the user name, and I don't want to force the users to re-authenticate. Is there any way to fetch this attribute without the password?
The Class attribute is a session cookie which is returned by the RADIUS server in the authentication packets and then sent back by the RADIUS client in the accounting packets.
I am pretty sure you cant refresh the Class attributes without re-authenticating.
If you want to change the value of the class attribute for an established session you may be able to issue a CoA request (dependent on NAS support).
Related
One user can log in through multiple systems with various IP addresses, so is there any way to deactivate one of his sessions? (or all other sessions except the current logged in one) if yes, how?
The thing I want to do is exactly like Telegram which you are able to close any of your activated sessions.
The question is not new here, it appears a couple times a month in different interpretations, and the answer is still: there is no such feature out of the box, but there are a couple approaches:
The first one is to use Reference Token (instead of jwt by default), then look through the persisted grants database and logout all the sessions for the target userId.
The other approach is to implement your custom session store based on a database (instead of the cookie based by default). Then you again have access to all the clients logged in with the given user id. Here is my old (but still valid) example of a hybrid (cookie + IDistributedCache such as REDIS) extension for the DefaultUserSession. Here you have to be careful with access token lifetime (make it reasonably short), as a jwt once issued can not be invalidated before its normal expiration.
I am working with the eBay API using OAuth on my current Meteor project app.
There is a section of the app where I can create an eBay account profile, and assign custom values to the account (such as nick-naming it, etc.). This is where I initiate the OAuth sign-in redirect process.
My question is about the 'state' parameter in the token requests. I understand that it is for helping prevent CSRF, but do I HAVE to use it that way? 'state' does seem to be optional after all.
Let's say I wanted to pass another value into the request call such as the string 'eBay Seller', and expect that the same exact string be returned in the response. I want to use that value to help my app determine which account to assign the returned tokens to (based on which account profile initiated the redirect link).
Is 'state' a valid place to pass in a variable that I expect to be returned exactly as sent? I considered using Session variables to handle this scenario, but quickly realized that this would not work, since the OAuth process takes me outside of my project's domain.
Does OAuth support passing variables that are expected to be returned as sent? Is sending my variable as 'state' allowed or even recommended (or absolutely not recommended?) Is there a better way to achieve what I want to do that does not involve updating database values?
Thank you!
You can send what you want as state. You should try to make sure it's not guessable though, to mitigate against CSRF attacks.
If you want to return useful information like 'ebay seller' then include something for CSRF (e.g. hash of the session key id) and the text 'ebay seller' and delimit them e.g.
2CF24DBA5FB0A30E26E83B2AC5B9E29E1B161E5C1FA7425E73043362938B9824|ebay seller
Now you have the best of both worlds: useful state info + CSRF protection.
Your redirect endpoint logic can check the hash of the session id matches and also confirm the account type from the initial request.
I have created an authentication server that implements OAuth 2 for authorization and it also provides local password authentication using the resource owner flow.
At the moment I always return a refresh token along with the access token which was an acceptable thing to do when I first implemented the feature. However now I need to implement a remember me feature in the client that uses the server. I could always just save the refresh token in the client when the user ticks the remember me checkbox but the token would still exist on the server and be usable even though the user didn't want it to.
What I want to do is simply pass a parameter along with the request that tells me whether I should create a refresh token or not.
So my question is. Is there some standard or recommended way of doing this using the fields provided in the spec or is it acceptable to simply add a parameter to the request to handle this use case?
AFAIK, there is no standardized way to choose whether to issue a refresh token or not.
I want to track all users (both authenticated users and anonymous users) , so far the solution i found are not good.
First of all, we can use a cookie but as we all know its not a reliable solution, second of all we, can use browser finger printing, but until this moment I did not find any solution for server side.
I found this solution valve but it is for client side and this one browserFingerPrint , I want an approach which user does not find any token in request , I want to create the key in server side so I can track users.
Does any one know any solution?
note : my server side technology is Asp.net Mvc
use case : users can comment on m site and also they can like or dislike comments, I want to allow all users to do this and also I want to track users before action (like or dislike)
No, there is no solution for what you want that doesn't use some form of a "token" which fingerprints anonymous users.
Let's see why.
An anonymous browser sends a series of bits of data, such as IP, browser agent and other headers. These should never be used to identify a user because they can be easily forged. They can be OK for tracking, and for most purposes IP address or some hash based on IP address and browser agent is sufficient. However this won't do for things which require security, such as commenter identification.
For commenter identification, it is necessary to prevent fraud. This is typically achieved by giving a unique token to each user. This can be transmitted in many forms, off the top of my head: cookies, headers, query string, POST parameters, or client certificates. However it does require a token issued by the server. If the client can generate a token from scratch, then it follows it can generate a fake token.
I'm thinking through how to open an endpoint to my customer so he/she can trigger changes in their model from an external website (aka an API i think?)
I plan on creating an action in my controller where I skip authentication and authenticity token check. I would create a long random string to give to my customer so when they submit a POST request, they would include the random string in the params to confirm identity.
Is this a secure way of doing what I'm trying to do? Is there another/better way of doing this?
I just want my customer to be able to pass me values and my app take actions based on these values.
what you are talking about is usually called client token authentication.
i use it for my app as well: https://github.com/phoet/on_ruby/blob/master/app/controllers/api_controller.rb#L23-L29
my implementation uses a header-field to exchange the token.
if you want to have a more sophisticated variant you should look at oauth.
in terms of security, you might take additional measures by whitelisting ip ranges etc.
of course, use SSL connections only!