gapi.oauth2 is being deprecated so I'm trying to set up Google Sign In using the new GIS Client. However I'm having a serious issue when the user grants access to scopes. The checkbox for one of the scopes is unchecked by default. Users often forget to check this and then our app just won't work for them. With gapi I could handle this by requesting additional permissions if they forgot to check the box. But the new GIS Client has no such functionality. Any ideas on how I might solve this problem? Thanks so much.
Normally, in an OAuth flow, in such a case you would make a new authorization request with the complete list of scopes that you need. The authorization server should be able to tell that you are asking for more scopes than the user previously consented to and ask for a new consent. It seems that GIS Client is using a standard OAuth flow, so I would try to solve your problem this way.
Related
I have to integrate Keycloak with an already existing C++ App, made up of several microservices. The database that is being used is MongoDB. Worth mentioning is that this app is a Desktop Client and will continue to be that way. I find Keycloak docs not that straightforward and would like some help on how to implement the security of the app to be delegated to Keycloak.
Saving the users and Keycloak data in MongoDB would be a nice feature. But as far as I know, that is not supported anymore, so I used PostgreSQL as a Keycloak specific DB.
From my research, I have found out that if I want to receive an Access Token without a browser, I have to use the Direct Grant feature in Keycloak. So making a POST request to
http://localhost:8080/auth/realms/my_realm/protocol/openid-connect/token
with my data (client_id, client_secret, username, password, grant_type=password) would supply me (the app) with an access token and a bunch of other data. The question is, is this the right way? If not, what should I do?
What about user registration?
What am I supposed to do with the access Token, my data is in my MongoDB?
Can you direct me to some plain-english tutorial/docs for keycloak?
Thank you.
When authenticating with a JWT should custom scope(permissions/claims) go in access token or id token? Seen it done both ways but not sure what is best practice.
I work with the Auth0 Community team and wanted to reach out. You can build out scopes using Auth0 when an app requests permission to access a resource through an authorization server, it uses the scope parameter to specify what access it needs, and the authorization server uses the scope parameter to respond with the access that was actually granted (if the granted access was different from what was requested). From what I am reading it sounds like using scopes and claims might be the direct goal here when working with a specific user. I hope this helps you on your path but if you have any questions please let me know!
I'm trying to figure out which OAuth2 grant to use for my application/saas. Or if OAuth2 is even the correct way to go.
The application:
The purpose of the application is for use and integration with e-commerce. So what I want is for the user is to go to my site and register an account. After the account has been created the user should be provided with credentials with which he/she can acquire an access- and refresh-token. The access-token should provide access to the users OWN resources and preferably use scopes to limit access. The user should the be able to get/post/put and delete stuff from his/her account as if working in the provided administration (SPA).
They should not have to go through the OAuth redirect flow, because they will be using the API from their servers.
My thoughts
First I considered going for the Client Credentials grant. But then I found out that it will not provide access to a user and it's resources.
I've started leaning towards using the Resource owner credentials grant. But I don't put a lot of faith in my users picking strong passwords. And in almost all documentation I can find, everyone seems to not recommend using this grant.
Maybe OAuth is not suitable for my project? Maybe I should go for some API Key which can be traded for an access token?
Any thoughts and/or input?
I've one link which may useful for you.
Link: https://github.com/lucadegasperi/oauth2-server-laravel/blob/master/docs/authorization-server/choosing-grant.md
Came to the conclusion that OAuth2 was not correct for my situation.
In the end I chose to go with a custom solution based on JWT.
Is there a line of code that bypasses the second app authentication screen where you select Allow or Deny? I would like our users to automatically be connected to the registered app.
Thanks!
No, it is not possible to bypass that step. If it were possible it would be a security hole.
Yes, is it possible, for paid networks. To be able to do this, your application should use an access token that must be authorized as verified network admin, so it could impersonate user access tokens, take a look at impersonation on Yammer documentation for more information about this.
I'm developing an application where Google Drive will be used to manage some documents. The idea is to create a document with some initial template data and provide the users access by adding them as collaborators of the document.
I'm familiar with the OAuth authentication process, I used it in another part of the system to manage the users Calendar...
But in this case these documents will be stored in a generic account of the company, so I can't have the approval prompt for authentication, since users won't have the password of the account.
I'd like to directly authenticate in this account, could be with the username and password hardcoded in the Java code.
Problem that this method of authentication was depreacated and I didn't found a relpacement.
Any ideas?
Thanks in advance,
Phillip
There are 2 ways that comes to mind:
Service accounts: best suited for server side OAuth with traditional backend
Regular Account owned by the application : similar to the process already in place for client side Oauth that you are already familiar with; Auth, store the refresh, ask new token if the AuthCode is expired, and so on.
I personally use and prefer the second solution more as I feel is more flexible to adapt in the future for Oauth Client Side get the tokens and use them server side.