I need to rotate the Google oAuth secret. For that I just need to go to the Google Cloud Platform Console > "APIs and Services" > "Credentials" > click on the client id under "OAuth 2.0 client IDs" > press the Reset Secret button.
Then I need to take the newly generated secret and configure my servers to use it instead of the old one. Until I do this, my service will be inaccessible.
How can I do this credential rotation and keep my service fully up through the operation?
I think the best way to rotate credentials without downtime is to create a new client. So the flow would be:
Create new credentials/client (identical to an old one)
Use credentials from the new client in your application
Remove the old credentials/client (credentials will not be valid anymore)
Related
I am working on building an app for a client inside the Dittofi Design Studio. I am on the basic package, so I cannot see by computer code.
I have built a collection of CRUD endpoints & actions & generated the code. Next & I want to make sure that some of my endpoints are only accessible by someone who correctly authenticates against them. Is there a setting for this inside the studio? How would this work for mobile apps authenticating against the endpoints?
Yes you can inside the studio.
If you look at the wrench in the bottom left, you should be able to create an "Authentication Profiles". You'd have to have users model/db table with username and password fields.
You would then have to have some sort of /sign-up, /login, and /logout endpoints (which would call the login web user and logout web user actions) for your authentication flow.
Finally, on the endpoint you want to lock down, if you look under its settings panel below the name, label and content type settings, you should be able to see how you can attach an authentication profile to the endpoint, i.e lock it down by making sure that only authenticated users can access the endpoint.
For mobile apps authentication agains the endpoints, I would generate a JSON web token (JWT) on the Dittofi end and have a secret key that's shared between the mobile apps and Dittofi to validate the token. That way the mobile app can send any requests to the Dittofi endpoints with that token. On the Dittofi end, I would have some token validation logic to validate that token.
This would require writing some custom Golang code to both generate the JWT and validate it using that secret key. That secret key can be stored in a Global variable (which can be though of as environment variables) accessible using that wrench in the bottom left corner of the Design studio.
Let me know if you'd like me to share the Go code that can generate the token and some example code that can validate your token using a secret key.
I am implementing login within a new native application (iOS and Android) and deciding on the kind of authentication to adopt. There are some quite clear guidelines around OAuth that state that this should be done using an external agent (browser) and this leads me to Authorization Code Grant with PKCE
https://www.rfc-editor.org/rfc/rfc8252
Implementation here: https://appauth.io/
However, my designers and product owners are sceptical. They dont see that kind of login very much (they dont like the address bar) and want to explore the Resource Owner Password Credentials option. Essentially direct login. Their argument is that it is simple and familiar.
I dont want to compromise security and as such I am resisting this option. But... I have read some articles that seem to suggest that this could be secure if I dynamically generate the client used for the auth request:
https://www.rfc-editor.org/rfc/rfc6749#section-10.1
The authorization server MUST NOT issue client passwords or other
client credentials to native application or user-agent-based
application clients for the purpose of client authentication. The
authorization server MAY issue a client password or other credentials
for a specific installation of a native application client on a
specific device.
This is backed up by AppAuth documentation here:
https://github.com/openid/AppAuth-Android#dynamic-client-registration
https://www.rfc-editor.org/rfc/rfc7591
Am I interpreting this correctly? I am considering initial user registration in-app that returns an access token that can be used to dynamically generate a client (with secret) that can be used for login using ROPC.
I am thinking to be secure then this dynamically generated client should only be used for login for the single user - one client per user, but maybe one client per device is also secure enough.
It seems a little 'hand rolled', so I am nervous. Am I right to be so?
I am developing software that will be used on small system at clients. The software is fetching Google calendar events from whatever Google account the client adds to it. The thing is that Googles API requires an secret key to work. As it is now, the system is working but the key is directly in the code, which means that the end user will be able to see it.
Firstly, is this a problem? I guess that because the key is "secret", there will be bad if a client can see it. Second, if this is bad, how should I do to avoid this? Is it even possible?
I should not be a problem since the key alone is not enough to generate an access token. You also need a refresh token or authorization code for that.
One risk is that, using the key, one of your clients (Alice) builds an OAuth authorization URL and tricks another of your client (Bob) into authorizing Alice's custom application to get calendar data. That problem only occurs if you're using the "installed application" workflow with the "urn:ietf:wg:oauth:2.0:oob" redirect URI.
If you want to avoid this problem, you can decide to host a web service that will handle the authorization for the embedded system. This web service will hold the client secret, and will receive call from your systems to either request authorization from a customer or refresh a token. Of course now you need to secure this web service, but you can probably do that with a customer-specific set of credentials. That way the only thing on the customer's premises are his specific credentials to access the webservice, nothing else.
Basically, I have the following scenario and information:
We're using HTTPS.
We want to authenticate a user by user/pass when they first log in.
After they are authenticated, I want any future calls to OTHER services (not the login service) to use the username and some sort of session (in case the password changes in the middle of a session).
I want to make sure my sessions can timeout and control them in a way that if a user tries to call a service and they don't have a session they get an error (cause they haven't logged in). Not sure if there's a WCF built-in way to do sessions this way or if I'll have to do something customized with a database.
I think we want to use WSHttpBinding (not BasicHttpBinding), 90% sure on this.
I just can't seem to figure out how to do this. Often time's I'll find information on the client code doing client.ClientCredentials.UserName.UserName = username and client.ClientCredentials.UserName.Password = password. But, that just doesn't work because what is my server checking against? I'm trying to grab that info and validate it against a database of user/passes. I'm not looking to use Windows Authentication or that sort (because I don't care who is logged into the computer, just who is logging into the app).
You want to use a Secure Token Service (STS) to authenticate and get a Security Token (maybe SAML) back that identifies the user which can then be passed to your other services and they can just use the identity information to identify and authorize because they trust the STS has verified the user's identity up front.
This is a large subject to discuss, so I suggest searching for WCF STS and doing some more research, but that's definitely the direction I'd recommend going. If you're going to build your own STS implementation, I also recommend looking into using the Windows Identity Foundation (WIF) components to ease your development efforts.
Here's the download link for WIF v1.0 which is the latest version at the time of this answer.
I am working on a cloud based application, I am assigned the work to implement Salesforce API in my application. I am done with all the authentication process and I am even able to push the leads in api.
But the problem is that I can only authorize my developer account thru it, the account from which I have taken consumer key and secret.
You need to create an package with your remote access settings (aka key & secret) and install it into the other org(s).