<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:content="http://purl.org/rss/1.0/modules/content/">
  <channel>
    <title>Authress Status - Incident history</title>
    <link>https://authress.instatus.com</link>
    <description>Authress</description>
    <pubDate>Wed, 12 Jun 2024 21:25:00 +0000</pubDate>
    
<item>
  <title>Authress Development Connections &quot;invalid_redirect&quot; specified</title>
  <description>
    Type: Incident
    Duration: 16 minutes

    Affected Components: Login &amp; Authentication API
    Jun 12, 21:25:00 GMT+0 - Identified - Identity Provider connections configured using the Authress development credentials prevented users from logging in with this connections.

A configuration change to improve the ability to better manage providers that used non-compliant OAuth interfaces, prevented the Connections using Authress Development Credentials for being used during login. Jun 12, 21:40:38 GMT+0 - Resolved - This incident has been resolved. A change has been rolled out to all Authress accounts to revert the problematic functionality and users should again be able to log in at this time.

The Authress Development Credentials are available for accounts to easily get up and running during the early integration with Authress. As usage matures, customers are urged to migrate from using these development credentials to ones owned by Authress Customers.

Authress Development Credentials should not be used in production environments as they are unstable and can be impacted by both the Authress Development Team as well as the provider they are being used with. If you are using Authress provided development credentials with any of your connections and are looking to move to using Customer provided credentials but are unsure how, the instructions for each of the connections are available in the Authress KB: &lt;https://authress.io/knowledge-base/docs/authentication/connecting-providers-idp&gt;

Or reach out to the Authress Development team via an Authress support ticket. 
  </description>
  <content:encoded>
    <![CDATA[<p><strong>Type:</strong> Incident</p>
    <p><strong>Duration:</strong> 16 minutes</p>
    <p><strong>Affected Components:</strong> </p>
    &lt;p&gt;&lt;small&gt;Jun &lt;var data-var=&#039;date&#039;&gt; 12&lt;/var&gt;, &lt;var data-var=&#039;time&#039;&gt;21:25:00&lt;/var&gt; GMT+0&lt;/small&gt;&lt;br&gt;&lt;strong&gt;Identified&lt;/strong&gt; -
  Identity Provider connections configured using the Authress development credentials prevented users from logging in with this connections.

A configuration change to improve the ability to better manage providers that used non-compliant OAuth interfaces, prevented the Connections using Authress Development Credentials for being used during login..&lt;/p&gt;
&lt;p&gt;&lt;small&gt;Jun &lt;var data-var=&#039;date&#039;&gt; 12&lt;/var&gt;, &lt;var data-var=&#039;time&#039;&gt;21:40:38&lt;/var&gt; GMT+0&lt;/small&gt;&lt;br&gt;&lt;strong&gt;Resolved&lt;/strong&gt; -
  This incident has been resolved. A change has been rolled out to all Authress accounts to revert the problematic functionality and users should again be able to log in at this time.

The Authress Development Credentials are available for accounts to easily get up and running during the early integration with Authress. As usage matures, customers are urged to migrate from using these development credentials to ones owned by Authress Customers.

Authress Development Credentials should not be used in production environments as they are unstable and can be impacted by both the Authress Development Team as well as the provider they are being used with. If you are using Authress provided development credentials with any of your connections and are looking to move to using Customer provided credentials but are unsure how, the instructions for each of the connections are available in the Authress KB: &lt;https://authress.io/knowledge-base/docs/authentication/connecting-providers-idp&gt;

Or reach out to the Authress Development team via an Authress support ticket..&lt;/p&gt;
]]>
  </content:encoded>
  <pubDate>Wed, 12 Jun 2024 21:25:00 +0000</pubDate>
  <link>https://authress.instatus.com/incident/clxcclfs44046cbofqyep4qjz</link>
  <guid>https://authress.instatus.com/incident/clxcclfs44046cbofqyep4qjz</guid>
</item>

<item>
  <title>Intermittent issue logging into the Authress Management Portal</title>
  <description>
    Type: Incident
    Duration: 5 hours and 40 minutes

    Affected Components: , 
Management Portal →
    Apr 2, 18:04:07 GMT+0 - Resolved - This has been resolved. Apr 2, 12:24:00 GMT+0 - Investigating - Some Authress admin users have been unable to begin new log in sessions and enter the portal. Existing sessions are unaffected by this issue. For new sessions generated for the Authress Management Portal, users might need to wait for a short delay (a few minutes) after initially starting the authentication flow to complete it.

This was the result of a mismatch on some of a version that was cached on some edge nodes supporting the Authress Management Portal and the expected handling for that version running in the Login &amp; Authentication API. The resolution was to rollback the update to the Management Portal until the advanced version was available on every edge node.

This neither affects integrations with the the Login &amp; Authentication API nor any customer deployments. 
  </description>
  <content:encoded>
    <![CDATA[<p><strong>Type:</strong> Incident</p>
    <p><strong>Duration:</strong> 5 hours and 40 minutes</p>
    <p><strong>Affected Components:</strong> </p>
    &lt;p&gt;&lt;small&gt;Apr &lt;var data-var=&#039;date&#039;&gt; 2&lt;/var&gt;, &lt;var data-var=&#039;time&#039;&gt;18:04:07&lt;/var&gt; GMT+0&lt;/small&gt;&lt;br&gt;&lt;strong&gt;Resolved&lt;/strong&gt; -
  This has been resolved..&lt;/p&gt;
&lt;p&gt;&lt;small&gt;Apr &lt;var data-var=&#039;date&#039;&gt; 2&lt;/var&gt;, &lt;var data-var=&#039;time&#039;&gt;12:24:00&lt;/var&gt; GMT+0&lt;/small&gt;&lt;br&gt;&lt;strong&gt;Investigating&lt;/strong&gt; -
  Some Authress admin users have been unable to begin new log in sessions and enter the portal. Existing sessions are unaffected by this issue. For new sessions generated for the Authress Management Portal, users might need to wait for a short delay (a few minutes) after initially starting the authentication flow to complete it.

This was the result of a mismatch on some of a version that was cached on some edge nodes supporting the Authress Management Portal and the expected handling for that version running in the Login &amp; Authentication API. The resolution was to rollback the update to the Management Portal until the advanced version was available on every edge node.

This neither affects integrations with the the Login &amp; Authentication API nor any customer deployments..&lt;/p&gt;
]]>
  </content:encoded>
  <pubDate>Tue, 2 Apr 2024 12:24:00 +0000</pubDate>
  <link>https://authress.instatus.com/incident/cluiou918332420bpmzot5a4pfl</link>
  <guid>https://authress.instatus.com/incident/cluiou918332420bpmzot5a4pfl</guid>
</item>

<item>
  <title>Issue logging into the Authress Management portal via SSO with Azure AD</title>
  <description>
    Type: Incident
    

    Affected Components: , 
Management Portal →
    Feb 5, 10:03:00 GMT+0 - Resolved - We&#039;ve identified an issue for some Authress administrative users that could not log into the Authress Management Portal. If you are using Azure AD in your Authress SSO Configuration, there were some changes to support the migration to support Microsoft Entra. Support for Azure AD SSO has been automatically restored.

If you encountered any issues authenticating during this time, the portal authentication has returned to normal. 
  </description>
  <content:encoded>
    <![CDATA[<p><strong>Type:</strong> Incident</p>
    
    <p><strong>Affected Components:</strong> </p>
    &lt;p&gt;&lt;small&gt;Feb &lt;var data-var=&#039;date&#039;&gt; 5&lt;/var&gt;, &lt;var data-var=&#039;time&#039;&gt;10:03:00&lt;/var&gt; GMT+0&lt;/small&gt;&lt;br&gt;&lt;strong&gt;Resolved&lt;/strong&gt; -
  We&#039;ve identified an issue for some Authress administrative users that could not log into the Authress Management Portal. If you are using Azure AD in your Authress SSO Configuration, there were some changes to support the migration to support Microsoft Entra. Support for Azure AD SSO has been automatically restored.

If you encountered any issues authenticating during this time, the portal authentication has returned to normal..&lt;/p&gt;
]]>
  </content:encoded>
  <pubDate>Mon, 5 Feb 2024 10:03:00 +0000</pubDate>
  <link>https://authress.instatus.com/incident/cls8w043i24660auoi3zb08i90</link>
  <guid>https://authress.instatus.com/incident/cls8w043i24660auoi3zb08i90</guid>
</item>

  </channel>
  </rss>