Now that using SMTP and basic authorization for sending email has been deprecated, what are you using in your solution instead? In this article, Senior Application Developer Xandon Frogget dives into the technical aspects of this important topic. If you know this area applies to you, and you are interested in scheduling a call with us to help get your system upgraded to OAuth 2.0, so you can continue sending email through your FileMaker solution, feel free to jump to the “Contact Us” section below or click the FREE CONSULTATION button at the upper right.
What is OAuth 2.0?
OAuth 2.0 is an open standard for authorization that allows users to securely share their private resources (such as data or API access) with third-party clients. It is commonly used as a way for users to grant access to their accounts on one website to another website or application.
One of the key concepts in OAuth 2.0 is the use of authorization “grants” to allow a client access to a user’s resources. Several different grant types can be used, depending on the requirements of the client and the resources being accessed. The most commonly used grant types are the authorization code and the implicit grant.
The authorization code grant involves the client redirecting the user to the authorization server, where the user is prompted to grant access to their resources. If the user grants access, the authorization server sends an authorization code back to the client, which can then be exchanged for an access token. The access token is used to access the user’s resources on the resource server.
The implicit grant is similar to the authorization code grant, but the access token is returned directly to the client without needing an intermediate authorization code. This grant type is typically used for clients that do not have a secure way to store the authorization code, such as JavaScript applications running in the user’s web browser.
The authorization request is made using a URI (Uniform Resource Identifier) in both the authorization code and implicit grant types. The URI includes several important pieces of information, including the client ID (a unique identifier for the client), the grant type, the redirect URI (the URI that the authorization server should redirect the user to after they have granted or denied access), and any other required parameters.*
I already use OAuth 2.0 in my FileMaker solution; what has changed?
Previously, many Claris FileMaker solutions that needed to use Google or Microsoft APIs with OAuth 2.0 authentication had to rely on outdated methods, such as the loopback IP address flow or the out-of-band flow. However, these methods have been officially deprecated and are no longer compliant after 2022. In early 2022, new clients were no longer able to use these options.
- One of the major issues with the loopback IP address flow is that it was susceptible to a man-in-the-middle attack. A malicious app could intercept the OAuth response and gain access to the authorization code.
- The out-of-band flow (OOB), while initially developed to support native clients without redirect URIs, poses a remote phishing risk. To protect against this vulnerability, clients must migrate to alternative methods.
What flow can you use now?
Looking at google’s OAuth 2.0 documentation, there are a few different scenarios:
- Server-side Web Apps
- JavaScript WebApps
- Mobile & Desktop Apps
- TV and Device Apps
- Service Accounts
In regards to Google APIs, the prerequisite for all of these are pretty much the same:
- Create a project
- Enable APIs for the project
- Create authorization credentials
- Identify access scopes
Which flow should I use?
Here is more detail about each flow.
Server-side Web Apps
- can use HTTP/REST – accessible only over HTTPS
- redirects to google for authorization
- uses a redirect URI
JavaScript WebApps
- can use HTTP/REST endpoint – accessible only over HTTPS
- redirects to google for authorization
- uses a redirect URI
Mobile & Desktop Apps
- Uses a custom URI scheme specific to Android, iOS, and UWP
- Generally consisting of using a signed/registered app id
- Previously could use the loopback and OOB – these have been deprecated
TV and Device Apps
- it is assumed that the apps cannot keep secrets
- limited scopes – save to google drive, get profile info, use for OpenID, etc.
- uses a browser in a separate device – URL with a code is used to provide consent
Service Accounts
- intended for server-only tasks
- uses JWT – (JSON Web Token)
- can use domain-wide authority
Given the options and the security concerns, only two flows are a good fit for FileMaker solutions. The Mobile and Desktop apps now require a signed app id. TV and Device Apps have limited scopes. JavaScript Web Apps require a backend server to receive the URI information. This leaves only Server-side Web Apps and Service Accounts as viable options.
That is great, but what does it mean for my FileMaker solution?
Previously many of the OAuth 2.0 integrations had used the Mobile and Desktop apps flow. They relied on using the loopback or OOB URI. As those have been deprecated, moving your solution to a different flow is important. Without getting overly technical, that leaves only two recommended flows.
- Server-side Web Apps
- Service Accounts
What’s the difference between the two?
When sending email through cloud providers’ APIs, there are two main flows: the server-side web apps flow and the service accounts flow. But what sets these two methods apart when using FileMaker.
Server-side Web Apps flow
- Perform the authorization process for server-side web apps on a secure network to prevent compromise of the redirect URI and parameters passed through the URI via HTTP and HTTPS traffic.
- Use tokens and refresh tokens issued after the authorization process to make REST/API calls. Ensure they are requested exclusively from a secure FileMaker Server, not the client, to prevent potential eavesdropping.
- Make all API calls exclusively from a secure FileMaker Server for optimal security.
- Protect any tokens, refresh tokens and secrets stored in the solution from unauthorized access, and enable encryption at rest on the server.
Service Accounts flow
- This option typically requires domain-wide authority for a Google or Microsoft workgroup account. This allows for greater access but also carries more security concerns.
- As with the server-side web apps flow, it is recommended that all API calls are only made from a secure FileMaker Server and never from the FileMaker client to protect against potential eavesdropping by malicious actors on HTTP and HTTPS traffic to and from the client.
- If domain-wide access to a workgroup is obtained, this flow can allow FileMaker Server to send emails on behalf of anyone in the workgroup. However, extra care must be taken to ensure that the server is secure and that any sensitive information is protected from unauthorized access.
To keep your Claris FileMaker solution secure, ensuring that all API calls and token requests are made from a secure server using either PSOS (Perform Script on Server) or FileMaker’s scheduled scripts is important. Also, ensure that authorization credentials and tokens are either not saved or saved securely. Never save them in clear text.
Service accounts do not use a redirect URI or an authorization process by the end user. They are intended for domain-wide authority for server-to-server tasks, which carries more security risks as it grants access to the entire organization. On the other hand, Server-Side web apps require a redirect URI, which it uses in the authorization process by the end user, and only has permission for the scopes defined for the authenticated account.
It can be difficult to obtain approval from an organization’s IT department for domain-wide access. In the case of email and domain-wide access, the FileMaker solution would have access to all emails within the organization’s domain. While this is useful for managing and sending emails on behalf of multiple people in the organization, it goes against best practices such as the least privileges. Server-Side web apps typically require less approval, are therefore more secure, and are less likely to cause friction.
So…what is a redirect URI?
A redirect URI, a “callback” or “return” URI, is a URL to which the user’s browser is redirected after the user authorizes an application to access their account. It is used in OAuth 2.0, and OpenID Connect authentication flows to allow the application to receive an authorization code or access token.
When a user clicks the “Allow” button on the authorization page, the authorization server sends the authorization code or access token to the redirect URI specified by the application. This URI is also used to validate the authenticity of the application and ensure that the authorization code or access token is sent to the correct location.
It’s worth noting that the redirect URI must be registered with the application developer’s authorization server (e.g., Google, Microsoft) for the authorization process to be successful.*
Configuring a URI for FileMaker requires a bit more attention to detail. We recently posted the first episode of our new podcast, FileMaker DevCast, on the same topic as this blog post. Please check it out!
If you are interested in learning more about this topic, please let us know in the comments, and we may cover it in a future blog post.
In conclusion
OAuth 2.0 is a robust and widely adopted method for authorization, and utilizing URIs to make authorization requests is crucial. By understanding how OAuth 2.0 and URIs work together, developers can create secure and easy apps for the end user. If you’re using Outlook or Gmail to send email through your Claris FileMaker application and need help transitioning to OAuth 2.0, please get in touch with us or fill out this form for assistance.
Find the episode transcript here
*Special note about this post and its authoring
I recently had the opportunity to use ChatGPT, a state-of-the-art language model developed by OpenAI, to help me write this blog article about automating emails with Claris FileMaker, OAuth 2.0, and security. I was amazed by how easy it was to use and how accurate the responses were. ChatGPT understood my requests and provided clear and concise information I could use in this article. It saved me a lot of time and helped me improve my writing quality. I highly recommend ChatGPT for anyone who needs assistance with writing, research, or any other task that requires natural language understanding. It’s a very cool tool that can help you achieve your goals easily. *
**Special note about art used in this post
I am also excited to share that some of the visual content in this blog article was generated using cutting-edge AI technology from Midjourney. This AI-based tool allows for creation of unique and captivating art, which I found to be a great addition to my blog article. By using Midjourney, I was able to add an extra level of engagement to my article, making it more interesting and interactive. I found it an easy-to-use and efficient tool, and I am thrilled with the results. I highly recommend Midjourney to anyone looking to add innovative and eye-catching visuals to their content. With this technology, the possibilities are endless!
All italicized sections were written by ChatGPT.
If you are interested in how ChatGPT was used to help write this blog article, let us know in the comments. Also, plan to listen to episode two of our FileMaker DevCast at the end of February, where ChatGPT will be the main topic of discussion.
Filemaker DevCast’s First Podcast Episode Is Now Live!
Portage Bay Solutions is excited to announce the launch of the Filemaker DevCast podcast. As a Claris Platinum Partner and a group of Claris certified developers, we want to create a space to gather to discuss various programming topics primarily related to Claris FileMaker. These meetings are opportunities for us to connect, share our insights and experiences, learn, and hone our craft.
Listen to the podcast now: https://filemakerdevcast.podbean.com/
