I've integrated Spring Security OAuth in my JAVA backend so that my mobile Android application (using the Facebook Login SDK) can benefit from Facebook Login. In the current flow, the APP uses Facebook Login SDK to fetch an access token from Android, and then passes to the JAVA/Spring backend. Then, another OAuth access token (specific to our backend) is issued and sent back to the application.
I wish I could automate the testing, in other words being able to generate fresh Facebook access tokens. And then test the whole stuff into the access to resources on my backend. My entry point is a Facebook access token.
I've failed in generated on-the-fly access tokens, then looked into never expiring tokens, I could hard-wire in my tests.
However, I've failed in generating never-expiring tokens : at best, changing a short-lived token to a long-lived token returns a token valid for 2 months only.
I've also tried https://www.facebook.com/dialog/oauth?client_id=xxxxxxxxxxxxxxx&redirect_uri=http://www.xxxx.com&granted_scopes=email,public_profile , but this only works when my cookies are available (only works from my web browser).
Also tried getting a device code, but I was stuck at the point where I had to "simulate" the user submitting the code into the web form.
Is there a known way to automate the testing ?
As #The1Fitz explained, "you cannot get a never expiring token anymore. You will need to make do with the maximum 2 month expiry date."
Related
Current situation
We have a very common system architecture with Spring Boot back-end and Angular front-end. For the mobile app we use Ionic, which basically uses same codebase as the front-end but adds additional features like biometrics etc.
User login is based on OAuth and access and refresh tokens are created once the user initiates the session. The access token has a short life span, where the refresh token is valid for a couple of days. As I said - very common auth flow.
What we want to achieve
Mobile app users should be able to login only once and then use the
app without the need to re-login every time the refresh token
expires.
For the "normal" front-end app refresh token expiration
policy should stay unchanged, meaning the user is forced to log in
again once the refresh token expires.
Possible solutions (from my perspective)
we pass an additional param to the login request specifying the client: web | mobile. If client is mobile refresh token validity is extended to expire in 1-2 years. Downside: this will break the whole idea of having tokens, that expire. I personally see this as a security issue.
we store credentials on mobile app local storage. Once we have session expiration, the app uses the credentials to re-authenticate. Downside: again I don't think this is a good idea having credentials stored on any device makes the flow vulnerable.
What I am looking for is kind of a best practice to solve this.
You are right, It's a security risk to have tokens that never expire or expire in a few years but they are used. Anyway, one thing you could do is to add a field in the refresh token endpoint that when you set it to true (defaults to false) it would also extend the lifespan of the refresh token. And you could periodically call that endpoint from your app. It should work even when It's in the background.
Or
If you wanna store the credentials in the local storage at least store them encrypted. You might need to create an endpoint that encrypts them because you should not have the private key in the mobile app. Then you'll probably need to create a custom authentication method that takes the encrypted credentials and compares them with the ones in the database.
I have two web applications that I've worked on in ASP.net Web API for a client. The two applications are hosted on the same domain, but in different virtual directories.
Each application has a data source with information about authorized users. I've been asked to set up a separate app that will allow a user to log in and issue an OAuth bearer token that can be used to access each web application.
I have the Owin stuff set up in one of my two apps with something of a boilerplate setup and it automagically makes the tokens work for me, but that's only within a single web application.
I have a general idea of how the OAuth tokens work: a user is authenticated and they receive a token that contains a user ID, a time stamp, and a cryptographic signature that says that the token came from my client's server and not somewhere else, and the Web API framework automatically checks that token for me when I decorate my API endpoints with the [Authorize] attribute.
I want to know how I can set this up so that the token is issued by one web app and consumed by another. I know that at a minimum, I need to make the two web apps work with the same key pair for the cryptographic signatures.
Can I please get some direction about how to make this happen?
I've found plenty of information on implementing Oauth2 using a user authorization step, but I'm trying to run a container that automatically scrapes a gmail inbox for attachments transforms them, and exports to prometheus, and I'm having trouble figuring out how to implement this library: https://pkg.go.dev/golang.org/x/oauth2/clientcredentials#Config or any other for that matter to retrieve a token without involving a manual user step.
Will doing this in Go require writing direct API calls since I can't find an existing library to handle this scenario? Would it make more sense to create a Google App password and use generic user/pass SMTP authentication?
First off i understand what you are trying to do.
You have a backend system running in a container which will access a single gmail account and process the emails.
Now you need to understand the limitations of the API you are working with.
There are two types of authorization used to access private user data
service account - server to server interaction only works with workspace domains. No authorization popup required.
Oauth2 - authorize normal user gmail accounts, requires user interaction to authorize the consent screen
If you do not have a workspace account and this is a normal gmail user then you have no choice you must use Oauth2, which will require that a user authorize the application at least once.
Using Oauth2 you can request offline access and receive a refresh token which you can use to request new access tokens when ever you wish. The catch is that your application will need to be in production and verified, because your refresh token will only work for seven days and then it will expire. To fix this and get a refresh token that does not expire means that your application must in production and verified. This means you need to go though Googles verification process with a restricted gmail scope which requires third party security check and costs between 15k - 75k depending upon your application.
I understand that this is a single user system but that does not mean that you still need to go though verification. When google added the need for application verification they did not take into account single user systems like yours.
Option
Have you considered going directly though the SMPT server instead of using the Gmail api? If you use an apps password you should bypass everything by loging in using the login and the apps password.
My current application access one of the Google APIs using "3-legs" OAuth 2.0. User authorizes the app on Google consent screen, then the app requests API on behalf of the user and shows him some fancy data loaded from API. Everyday my application loads and transforms data from this API, so when the user comes next time, he sees the most relevant and actual data.
Everything works fine on the start, but as time goes, I faced two problems:
1. Query limits.
2. Token lifetime.
My question is dedicated to the second one, that I refer as "token lifetime". After some amount of time, the access token expires, and when user comes back to the app, our app obliged to send him to consent screen again. Moreover, all the time while access token has been in expired state, my app cannot load relevant data for user.
How can I solve this problem? How to continue lifetime of access/refresh tokens? Would Service account help? Would Service account work for Google Search Console API for every user, or should the user be a G Suite user inside my domain or what?
These questions are completely unclear from the official documentation here and from the Search Console API documentation.
If you have past experience with Google's APIs, please help me!
Thank you
When you use OAuth with user-consent, you do not need to prompt the user for consent repeatedly.
[a] If your usecase is entirely online and you want to be able to request a token each time the user visits your app, use the Google Sign In library or see this documentation for client-side apps.
[b] If your usecase is that you want to be able to obtain access tokens even when the user is not present, then you need to request an authorization code and store your refresh token. Your refresh tokens are longer-lived tokens and can be exchanged periodically for access tokens.
I would like to access my own facebook news feeds using spring social facebook. I have registered my app and i could able to get app key and secret key. How to generate facebook access token for given app key and secret key using spring social facebook(programmatically)?
Now i'm using the link https://developers.facebook.com/tools/explorer generate the temporary access token which is valid only for 60 minutes.
How to generate the access token in my java application itself without having any login page redirecting to facebook redirecting back, etc.
If you're wanting to use the token to access user-owned resources at Facebook (e.g., the user's timeline, friends, etc) there's no way to get a token without involving the user. That's on purpose so that you aren't allowed to fetch data or write data to Facebook without getting the user's permission to do so.
But if that's what you want, then you must redirect the user to Facebook and back. This is OAuth 2's authorization code grant. Spring Social's ConnectController can help you with this.
You might be able to do it via the JS API, but it's been awhile since I've done it that way and I know a few things have changed at Facebook in that regard. And it probably relies on OAuth 2 Implicit Grant (which involves a redirect).
There is another way to obtain an access token without redirecting: Via OAuth 2's client credentials grant. But I don't think that's what you want. Such a token can only be used to work with non-user resources (such as Facebook's Insights API). But if that's what you want, then you can use OAuth2Template's authenticateClient() method.
Again, to be perfectly clear, it is very much by design that you can't obtain a user access token without involving the user. And with Facebook, that will require redirects.