Here is the scenario:
Web App (webapp) authentication uses OAuth Authorization Server SSO
by setting spring.oauth2.sso.* properties.
User authenticates and webapp now have user credentials and access_token. Application then uses this token to call certain microservices on the backend.
When token expires it will eventually get 403 Unathorized.
Since we dont have refresh token should we just force user to login again?
What if we want user to stay logged in longer then token's TTL?
Any thoughts?
If I understand your question correctly, absent having a refresh token, the user will need to login again as this is the only way to get a new access token without it.
Related
I have keycloak version 20 installed, and api request to authenticate with username and password via REST API. I want to add remember_me to the request body, so I can extend the users refresh token (if the user wants it). Is that possible? I don't want to extend the refresh token lifespan for all sessions.
The API call is to the URI
/realms/{realm}/protocol/openid-connect/token
I also enabled the remember me for the realm, and it is available if I authenticate in the browser.
I have keycloak version 20 installed, and api request to authenticate
with username and password via REST API. I want to add remember_me to the request body, so I can extend the users refresh token (if the user wants it). Is that possible?
I am afraid this is not possible with Direct Access Grant Flow
From the Keycloak documentation section about the Remember Me functionality:
A logged-in user closing their browser destroys their session, and
that user must log in again. You can set Keycloak to keep the user’s
login session open if that user clicks the Remember Me checkbox upon
login. This action turns the login cookie from a session-only cookie
to a persistence cookie.
In Keycloak this feature relies on the browser cookies to work. For example, if you login with a user in one browser and then try to access the same account in another browser you are forced to authenticate the user again. It only works in the same browser (if cookies are enabled) because it was there where the cookie was originally created. Consequently, out-of-the-box, I do not see how this would work with the Direct Access Grant flow.
I'm using keycloak, but I don't understand how the verification of authentication is made after the user authenticate in the app.
For example I have an app secured with keycloak, when a user try to access it, he/she will be redirected to authentication page, then (I guess, and correct me If I'm wrong) the user will have a token that need to be send with every request.
On a complete system secured with Keycloak:
A user clicks from a public page to navigate to a protected area within the application. The link to this protected area is in your application settings in keycloak admin console.
The user will be redirected indeed to the Keycloak authentication page. After providing Username and password, Keycloak redirects the user back to your application again with a code that is valid to a very short period of time.
The application communicates this code to Keycloak along with the Application ID and the Application secret, then Keycloak replies with the Access token, ID token, and a Refresh token. your Application will need only one of these tokens to see which claims the user has, and according to the claims, the user will be granted or denied access to protected URL(s)
Authorization code/standard flow:
From your app you're redirected to Keycloak's login page.
You give your username and password to Keycloak, and if these are correct, you will get a redirection to your app, and get an authorization code.
Your app send this auth_code and its id and secret to keycloak, and keycloak give you a token.
There are two more flows: resource owner credentials, and client credentials.
Facebook documentation states that
. At any point, you can generate a new long-lived token by sending the person back to the login flow used by your web app - note that the person will not actually need to login again, they have already authorized your app, so they will immediately redirect back to your app from the login flow with a refreshed token - how this appears to the person will vary based on the type of login flow that you are using, for example if you are using the JavaScript SDK, this will take place in the background, if you are using a server-side flow, the browser will quickly redirect to the Login Dialog and then automatically and immediately back to your app again.
What does it mean that the person does not actually need to login? Does not he have to pass his credentials again? If not how does FB is authenticating the user and getting the refreshed access token?
Yes but you need that the user visits your web app. Then you check for login status, if it is "connected" you will get a new short-lived token without even making the user login again. That's because the token has information about apps already authorized by user. If not the case or the user hasn't login in FB then you need to call the login function.
Once you have the token you can create a new long-lived token again.
My app uses Facebook Javascript SDK authorization on client side, and for authorized user app fetches access token from Facebook API, using facebook cookie with signed request and provided code, and store it into database.
Everything is working fine, but i'm wondering, when I should refresh stored access token? What if user have changes password, and have signed in/connected again.
As I understand, now she has new access token, and app should load it from Facebook. But how I can understand when I should check for a new token? Check on each request with facebook cookie doesn't work, because it's few request per second for each user (event if she didn't change a password). Or maybe i'm doing something wrong?
I mean:
I've authorized user on client side
I've cookie with signed request
Signed request is pretty enough to authorize user on server side (validate user credentials)
I can get access token by calling Facebook API, anytime when user user makes request to my app (because I need a code from signed request). So, i'm doing it when I don't have stored access token or existing access token has expired.
access token just stored in database, and can be used anytime, in different thread, maybe few minutes later (mean we don't have user request and cookie with signed request)
What if stored access token not expired, but invalidated on facebook side? I need to fetch new access token, but cookie has gone at this moment.
Currently I see only one way: store code from signed request into databse, and when we have found that we have invalid access token, try to load it. But i'm note sure that it's proper way, and not so much usable for most cases
You have client token and server token, the client one is short lived (a few hours) and the server one is long lived (60 days).
The token on the client side should not bother you too much since you can get a new one easily as it states in the "Handling Invalid and Expired Access Tokens" guide:
Desktop Web and Mobile Web apps which implement authentication with the Javascript SDK
Calling FB.getLoginStatus() or ensuring status: true is set when you
call FB.init() means that the next time a user lands on your
application and is signed into Facebook, the authResponse object you
are passed as a result of those calls will contain a fresh, valid
access token.
In this case, its simply the act of the user using your application
which implicitly generates a new access token.
The token on the server side, which you persist in the db, can not be as easily reproduced, the user has to be sent to the auth dialog again:
Desktop Web and Mobile Web apps which implement the server-side authentication flow
To obtain a fresh access token in this case you must pass the user
through the full server-side flow again: i.e. obtain a code and
exchange it for a new access token.
However, assuming the user has not de-authorized your application,
when you redirect the user into the OAuth Dialog, the user will not be
prompted to reauthorize your application, and will be immediately
redirected to your redirect_uri. This means that the re-authentication
process can appear transparent to the user.
You can of course send a client token to the server and persist that, but it's pretty pointless since it's short lived.
Another option is to use the new endpoint to extend a valid client token on the server side and then persisting that.
As for "how to know when do get a new token", on the server side when you are making api requests just check the response and see if an error returned and if so what it is (there's a list in the first url I added).
If the token has expired then just send the user to the auth dialog again (you can return some kind of code to the client side and do it from there) and then save the new token to the db.
There's no need to check cookies, those are used in the background but you should not have anything to do with them.
Edit
Don't use the cookies, they should not concern you at any time.
What you should do:
On the server side you should follow the instructions in the Server-Side auth guide, get the "code" and exchange it with a token.
That token will have 60 days.
Use that token, which you store in your db, as needed (other threads, what not) and when you are getting an error back from facebook saying that the token has expires just navigate the user back to the auth dialog page.
You can not use the "code" to get more than one token so that won't help you.
If the user session (and token) got invalidated (for various reasons) you will still get an error back from facebook when trying to make an api request, when that happens just send the user to the auth dialog again.
As I understand it, this is the basic process for new Facebook iframe canvas apps using the OAuth2 API in a nutshell:
Redirect to (or have user click link to) app's authorization URL
User authorizes and is redirected to your callback URL
Callback uses "code" parameter to get a access token
Access token is used with Graph API to pull or push information
The problem is that access tokens expire relatively quickly and need to be "refreshed", so my questions are 1) how do you detect that the token has expired aside from trying to use it and simply getting an error? and 2) what is the best practice for obtaining a new token?
Currently, I just detect that there was an error trying to get the user's information with their access token, then redirect to the authorization URL again -- since they already authorized the app a blank page flashes by and they are redirected back to my app callback where I get a fresh token. It's so clunky I can't believe this is the proper method.
The only way to tell if a cookie is valid is to use it and catch the error if it is expired. There is no polling method or anything to check if a token is valid.
To get a new token, simply redirect the user to the authentication page again. Because they have already authorized your app they will instantly be redirected back to your app and you will have a new token. They won't be prompted to allow since they have already done that.
In short, there are no tricks to this. You are already doing it correctly.
Recently, facebook has made some changes to access tokens which allows them to be refreshed periodically.
https://graph.facebook.com/oauth/access_token?
client_id=APP_ID&
client_secret=APP_SECRET&
grant_type=fb_exchange_token&
fb_exchange_token=EXISTING_ACCESS_TOKEN
For more details, check here: https://developers.facebook.com/docs/roadmap/completed-changes/offline-access-removal
//you just need more step because the access token you are getting will expire in 1 hour
//you can overcome this in step 5
1-Redirect to (or have user click link to) app's authorization URL
2-User authorizes and is redirected to your callback URL
3-Callback uses "code" parameter to get a access token
4-Access token is used with Graph API to pull or push information
5-exchange short-lived access token you just got with 60 day access token
https://graph.facebook.com/oauth/access_token?client_id=APP_ID&client_secret=APP_SECRET&grant_type=fb_exchange_token&fb_exchange_token=EXISTING_ACCESS_TOKEN
6-after 60 day the user must login again to your app and the steps from 1-5 will be repeated.
--the real problem you will face is how to make the user visit your app page again
Facebook has removed the feature of refresh the access token on the "behalf of" mode. The best and easy way is to redirect the user to facebook login page to re-oauth the app.
Find facbook doc here
if user has already authorized your application and access token expired. you can redirect user to authentication page again. but oauth dialog doestn't show because user already authorized your application. he will redirect to redirect_url parameter you used.