I have been trying to make my application verified for quite some time already. The main problem that I have is that my homepage and other pages(except web hooks for push-notifications and oauth2 flow) are private (because it's dev environment, not prod) and if you try to access them from the Internet, firewall will not allow you doing so.
Considering what I wrote above, I posted OAuth Developer Verification Form with the links to my app that aren't accessible for the external network. Now I got the following message from Google:
Dear Developer,
Thank you for your patience. Please reply back with a test account email and password, so we can experience the user sign-up flow, validate the app services and then proceed with OAuth Verification process.
Please do not hesitate to reach out to us if you have questions or concerns.
Even if I provide the account in my application, Google will not be able to reach the application.
I am sure that there are thousands of applications that have DEV/QA and other environments that aren't accessible from the Internet.
How do you go through verification process?
How do you go through the process in general?
What URLs do you specify in the form? Are they private?
How do you provide user for the Google if you application is not available through the Internet(only web-hooks are available)?
This was so easy for PROD environment, but appears a real nightmare for DEV environments.
Thank you!
Related
Question
If InstalledAppFlow requires client secret json file to perform oauth2 authorization, how actual real-life applications using Google API are distributed?
Is client secret json file should be considered as part of application and included as constant?
Context
Currently I am learning how to use oauth2 to authorize google APIs access with python module google_auth_oauthlib.
And I found that Oauth2 authorization process itself require client secret files for InstalledAppFlow authorization method, but I never seen an application that asks for authorization asking for client secret.
After countless searches all I could find about it was this, from google identity docs.
The process results in a client ID and, in some cases, a client secret, which you embed in the source code of your application. (In this context, the client secret is obviously not treated as a secret.)
And from google cloud docs
Save the credentials file to client_secrets.json. This file must be distributed with your app.
Is this explaining that I should embed(include) client secret as constant in the code itself?
The issue with the client id and client secrete is that they need to be kept secure. Googles TOS requires that developers keep their client id and secrete secure
Asking developers to make reasonable efforts to keep their private keys private and not embed them in open source projects.
This can cause issues with for example open source applications. Can I really not ship open source with Client ID?
I have had a few conversations with the Oauth2 team at google over the years. Installed applications those that are compiled anyway can compile the client id and client secrete internally however that would not stop anyone from decompiling the application and retrieving the client id and client secret.
I was told that they are aware of that issue and that there is really no way around it.
I have seen other option where the client id and client secret would be sored on the server and then the installed application would request them from a web api. This is another option but you are sending them across HTTPS it should be considered secure even if you double encrypt them.
The fact of the matter is there really is no way around it. The main thing is that you should not release an application with for example a settings file where the client id and client secrete appear in clear text that would IMO be to great a risk you would need to compile it into your application or at the very least encrypt it some how.
You wont stop someone who really wants to get it from getting it but you will stop most people.
Why installed apps are the issue.
There are serval types of applications. Mobile, web, installed.
With mobile and web there are ways of configuring the client so that you can ensure that they only work form your server. With Web you have a redirect uri, with mobile there is the actual mobile api id.
With installed applications this is not possible because they mostly run on localhost. There is no way for you to know where the app is running so they are left open. So if anyone got ahold of your client id and client secret then they could use it for their app. Users would have no way of knowing it wasn't your official app and neither would google.
As you have a python script why not consider instructing your users in creating their own client id and client secret then they will be independent.
I've been following Microsoft's Teams C# tutorials found here, and have been successful for the most part. However, I cannot seem to get my app to work when I host the messaging endpoint myself rather than via their Azure service, which is not an option for me ultimately as the pricing is outrageous for what we need it to do.
I'm hosting the endpoint myself by publishing the sample project and ensuring it's externally available via HTTPS. I can access a custom tab within Teams, so I know that it's online, it's just the messaging endpoint that seems to fail with an "unable to reach app" error when I try and use the messaging extension via a chat window.
When debugging using dev tools, I get 502 error: Bot returned unsuccessful status code Forbidden, error code 1008. Every potential solution I've seen for similar issues hasn't worked for me thus far, though I still feel like it's something incredibly obvious. Are there special steps that need taking when hosting the endpoint yourself? The docs do a very lousy job of explaining the process, probably because Microsoft want you to pay to host the app on Azure.
This is usually caused by the app id / app key not being registered or used correctly in your app, so it's not authenticating to the bot framework service properly. Where/how you do that depends a bit on what sample code / project template you started with, but it's usually somewhere in a .config file (or previously in a .bot file).
The information that you need will be in:
App Id: The Bot Settings page in Azure
App Key: from the Bot settings page, where you got the AppId above, it links to the App registration itself - within there you'll find the section on keys, and you can create a new key (if you've lost the original one)
I know it's generally an error when AppID validation fails. The bot app requests Azure AD to verify the identity.Could your web server access to Azure AD? If you deny to access to outbound with firewall, you should allow Azure IP range.
Turns out it was purely a network issue, that as of yet we still haven't actually figured out. But we tried hosting the app elsewhere and it was fine. That's my recommendation if anyone else has the same problem!
I'm trying to figure out how to migrate a system that is currently using ACS to Azure AD. I've read the migration docs provided by Azure and have looked through the Azure AD docs and the sample code but I'm still a bit lost as to what the best approach for my situation would be.
I've got a web API that has about 100 separate external systems that connect to it on a regular basis. We add a new connections approximately once a week. These external systems are not users--these are applications that are integrated with my application via my web API.
Currently each external system has an ACS service identity / password which they use to obtain a token which we then use to authenticate. Obviously this system is going away as of November 7.
All of the Azure AD documentation I've read so far indicates that, when I migrate, I should set up each of my existing clients as an "application registration" in Azure AD. The upshot of this is that each client, instead of connecting to me using a username and password, will have to connect using an application ID (which is always a GUID), an encrypted password, and a "resource" which seems to be the same as an audience URL from what I can see. This in itself is cumbersome but not that bad.
Then, implementing the authorization piece in my web API is deceptively simple. It looks like, fundamentally, all I need to do is include the properly configured [Authorize] attribute in my ApiController. But the trick is in getting it to be properly configured.
From what I can see in all the examples out there, I need to hard-code the unique Audience URL for every single client that might possibly connect to my API into my startup code somewhere, and that really does not seem reasonable to me so I can only assume that I must be missing something. Do I really need to recompile my code and do a new deployment every time a new external system wants to connect to my API?
Can anyone out there provide a bit of guidance?
Thanks.
You have misunderstood how the audience URI works.
It is not your client's URI, it is your API's URI.
When the clients request a token using Client Credentials flow (client id + secret), they all must use your API's App ID URI as the resource.
That will then be the audience in the token.
Your API only needs to check the token contains its App ID URI as the audience.
Though I want to also mention that if you want to do this a step better, you should define at least one application permission in your API's manifest. You can check my article on adding permissions.
Then your API should also check that the access token contains something like:
"roles": [
"your-permission-value"
]
It makes the security a bit better since any client app with an id + secret can get an access token for any API in that Azure AD tenant.
But with application permissions, you can require that a permission must be explicitly assigned for a client to be able to call your API.
It would make the migration a tad more cumbersome of course, since you'd have to require this app permission + grant it to all of the clients.
All of that can be automated with PowerShell though.
My institute currently has a local domain running on Windows Server, like a lot of business networks. I would like to build a web app that users can log into using their Windows login credentials, so that they don't have to manage multiple usernames and passwords.
Is this possible?
The app would be built with node.js and designed so that it could launch on mobile devices that are not on the network.
Also, I'm a student so please forgive my overwhelming ignorance on the matter. :)
The basic requirement is to centralize the authentication and authorization of multiple SaaS applications to ease development (each SaaS application using minimal code to authenticate against a single source) and when necessary provide SSO. The authentication mechanism must handle the following options available to the user:
Use Third Party Authentication -- Google
Use our centralized authentication
Use the corporate provided authentication (ADFS)
In my research, I have found many, many ways this can be done and have found OpenAM to be the most complete solution, but then I came across FreeRadius which could also be used.
My Questions are:
There seems to be a plug-in for each tool where one can use the other together (OpenAM - authenticate against radius server), but is there any use case where FreeRadius would be preferred as the SOLE authentication server over OpenAM.
Does OpenAM require that a web agent installed for the server - if all I am doing is serving a Restful Interface (developed in Node.js) - is it possible to authenticate users without installing a web agent (there is no web agent for Node.js).
Can I pass user credentials from Browser -> Server (node.js) -> OpenAM thereby not giving the user the OpenAM login screen. The OpenAM token will be passed from OpenAM -> Server -> Browser (setting the cookies's origin as the SaaS's application.
That is each SaaS application server will serve as a "proxy" for user management (authenticate, authorize, and manage[create|update|delete] users)
Thank you
I'm early to the Open Identity Stack game but I am deploying an OpenAM (and OpenIDM + OpenDJ) based solution to handle exactly the solutions you mention.
direct answers:
As far as handing sole authentication over to FreeRadius I don't see why you would want to but anything is possible. Given your mention of the multiple directories (identity sources - google, ADFS, and your centralized authentication) I would think hooking up OpenAM to provide the RADIUS authentication (i.e. OpenAM RADIUS hook, not FreeRadius) would make sense.
No, a web agent doesn't have to be applied but it may make sense. There are some node.js pieces to help (https://github.com/alesium/node-openam). You just need to talk from your server to the OpenAM side (REST) and that should be good.
You can do that or you can just skin the OpenAM login screen to look like your own. I'd suggest the latter as you're then relying on OpenAM for the login screen security. If you're doing a pure proxy then you take that burden on. Your call as a design decision obviously.
good luck!
you're comparing a RADIUS sever with a Web SSO solution ... I'm not sure if this makes sense.
It seems FreeRadius does not have that many 'auth backends' (like Oauth to leverage Google Auth)
I am looking into the solution for a similar requirement myself, but I am looking to integrate 2FA as well. I have seen so many different solutions, but haven't pinned down the best one yet. Here is what I have come up with so far:
RCDev OpenID seems to be pretty comprehensive, and it is free for cases with less than 40 users.
Green Rocket's GreenRADIUS is expensive, but they have plugins for every scenario and it can work.
Red Hat's KeyCloak could be used in combination with TACACS+ or FreeRADIUS to accomplish this