I'm trying to build an IdP that other applications can use to authenticate users using Spring authorization server.
I don't want the user to get logged in automatically, but since the /oauth2/authorize endpoint need an authenticated user that's stored on the session I don't really know how to get around it.
It feels like there should be a fairly simple way of achieving this without the need to customize session handling?
Related
How do i get access to the currently authenticated users access token in a Keycloak Service Provider Interface when the user has just logged in?
Current situation:
I am doing a manual Password Grant with Apache HttpClient inside a custom User Federation/Storage Provider when the user is performing a login with username and password.
The users access token is then used to call an internal API with his authentication context. This API call with the users bearer token is required for auditing/GDPR purposes since the user gives multiple consents when logging in.
I am assuming there is no way to get the current users authentication context within a user storage provider since the user is not yet authenticated at that point in time, right?
Is password grant the correct way to obtain a user auth context/token at that time? Another option might be to chain SPIs, e.g. use an Authentication SPI and intercept the token there. But it seems you cannot overwrite an existing Auth flow.
The last and maybe best option would be to create an Event Listener Provider. But do i have access to the access token there?
I would really appreciate some input because this whole endeavour feels a bit off.
Another option (which makes more sense for me) would be to use a client id to authenticate as a service (client authentication), in order to perform the auditing. That way you don't even need the user to be authenticated at that point. I see it as a better solution, since, apart what I have said, auditing is actually a system related chore. If you let any user do auditing, they could script some code with a valid token to perform massive/fake auditings by their own.
It makes more sense to leave it to a concrete client, with a concrete role and request that role for the auditing process.
I am building an API for my rails app. Through that API I will log users in and allow them to interact with their data.
On top of that users authentication, I will also like to make sure only my iOS app has access to the API, and eventually my own web app.
I want to make sure no one else will be using the API, so on top of the user authentication, I will like to protect my API with a token for each of my apps.
How do you usually solve this problem? Would I have to pass that token over on each call in order to authenticate that the call is coming from a valid client and identify which client it is (web vs iOS).
I will very much appreciate any pointers or if you know of an article explaining how to deal with this.
As you are already using jwt's to authenticate your user, why not just use the functionality of jwt to include additional information in the token, in this instance some form of hashed string that you can verify server side if it is a valid "client id".
On each request you could refresh the string.
Kind of dual authentication in each request. the user and the client.
As background, I'm using the Google OAuth2 NodeJS client, but I think my question is more abstract / technology independent.
My website is single-page application that communicates via AJAX to the server.
When a user first visits my website, I perform an OAuth2 flow which redirects them to Google to log in, and then redirects back to my site with an access token. I store this access token in a cookie, and use it to handle various calls made to the server via AJAX.
My challenge is that I'm unsure what to do when that access_token expires. Should I be storing the refresh_token in a cookie as well, and using that, or are there security issues in doing so?
Should I be redirecting the browser to perform the login flow again? That seems fairly ugly for a single-page application.
You can do the OAuth2 flow via js in the background(like the login flow with the popup window), and if the access hasn't been revoked for you app id, then the user shouldn't see anything about it. Although you can set a hint on the user email to authenticate, this may not work.
The other way that you mentioned, is the refresh token, that you can use to ask for a new access token, without user interaction. Maybe that would be the better idea, but remember, that you will only get a refresh token if you set the access type to offline.
I have an iOS app that is using the Facebook SDK to authenticate. I am then able to use omniauth, devise, and omniauth-facebook-access-token (via AFNetworking) to create a user on the server for that facebook account.
Now I need my iOS app's user to be able to "have a session" on the RoR server - I could do that by passing some information in the headers or URL for each request to be authenticated or I could use a cookie. When the app makes API requests (JSON usually), I need those requests to be in the context of the user who has been authenticated.
What is the best practice for having an authenticated RoR user on an iOS app in this situation?
Some options that come to mind:
Maintain a cookie on the client
Send a piece of information for each API request in a header or somewhere else (access_token? user_id?)
My concern is that I want to be able to add additional oauth2 authentication providers without redoing this code.
You need a token to authenticate the user, you should also keep sending the csrf-token in order to keep your app secure. Take a look at this question, and see how the csrf is handeled in its answer.
I'm trying to use OAuth with .NET (DotNetOpenAuth) to send updates to a Twitter account via a web application. I understand the basic workflow of OAuth and Twitter.
Where I'm confused if is it useful in a server web application? I don't want any user interaction.
But how it seems after an application start, the request token needs to be recreated and also an access token. This involves user interaction.
What is the correct workflow for my case?
Storing the request token or access token in config file?
Or the easist way, using HTTP basic authentication?
Thanks
If I understand you correctly your application will not be interacting with Twitter on behalf of your users but will be acting as the Twitter account for your application.
In this case there are 2 main factors to consider.
1) Do you want "from API" attached to each status as will be if you use basic auth or your applications name will happen if you use OAuth.
2) Do you want to put in the extra effort to implement OAuth.
If you decide to go with OAuth you would store your apps consumer key/secret and the accounts access token in configuration just like you would store the accounts screenname/password.
Your "request token needs to be recreated" phrase suggests you might be running into the problem where every time your user visits you need to re-authorize to Twitter, and perhaps you're looking for a way to access the user's Twitter account while he's not at your web site, and how can you do this when their token isn't fresh from being re-authorized. Is that right?
If so, the user isn't supposed to have to re-authorize Twitter every time they visit your site. The token is supposed to last a long time, which would also allow your site to access their Twitter account when they are not directly interacting with your web site. The problem may be that you haven't implemented the IConsumerTokenManager interface, but are instead using the default InMemoryTokenManager, which is for sample use only, since this memory-only token manager loses tokens every time the web app is restarted. Your own implementation of this simple interface should store and read the tokens out of some persistent storage such as a database.