<?xml version="1.0" encoding="UTF-8"?>
<feed xml:lang="en-US" xmlns="http://www.w3.org/2005/Atom">
  <id>tag:authress.instatus.com,2005:/history</id>
  <link rel="alternate" type="text/html" href="https://authress.instatus.com"/>
  <link rel="self" type="application/atom+xml" href="https://authress.instatus.com/history.atom"/>
  <title>Authress Status - Incident history</title>
  <updated>2024-06-12T21:25:00.000+00:00</updated>
  <author>
    <name>Authress</name>
  </author>
  
<entry>
  <id>tag:authress.instatus.com,2005:Incident/clxcclfs44046cbofqyep4qjz</id>
  <published>2024-06-12T21:25:00.000+00:00</published>
  <updated>2024-06-12T21:25:00.000+00:00</updated>
  <link rel="alternate" type="text/html" href="https://authress.instatus.com/incident/clxcclfs44046cbofqyep4qjz"/>
  <title>Authress Development Connections &quot;invalid_redirect&quot; specified</title>

  <content type="html">
  <![CDATA[
    <p><strong>Type:</strong> Incident</p>
    <p><strong>Duration:</strong> 16 minutes</p>
    <p><strong>Affected Components:</strong> Login &amp; Authentication API</p>
    <p><small>Jun <var data-var='date'> 12</var>, <var data-var='time'>21:25:00</var> GMT+0</small><br /><strong>Identified</strong> -
  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..</p>
<p><small>Jun <var data-var='date'> 12</var>, <var data-var='time'>21:40:38</var> GMT+0</small><br /><strong>Resolved</strong> -
  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..</p>

        ]]>
  </content>
</entry>

<entry>
  <id>tag:authress.instatus.com,2005:Incident/cluiou918332420bpmzot5a4pfl</id>
  <published>2024-04-02T12:24:00.000+00:00</published>
  <updated>2024-04-02T18:04:07.112+00:00</updated>
  <link rel="alternate" type="text/html" href="https://authress.instatus.com/incident/cluiou918332420bpmzot5a4pfl"/>
  <title>Intermittent issue logging into the Authress Management Portal</title>

  <content type="html">
  <![CDATA[
    <p><strong>Type:</strong> Incident</p>
    <p><strong>Duration:</strong> 5 hours and 40 minutes</p>
    <p><strong>Affected Components:</strong> , 
Management Portal →</p>
    <p><small>Apr <var data-var='date'> 2</var>, <var data-var='time'>18:04:07</var> GMT+0</small><br /><strong>Resolved</strong> -
  This has been resolved..</p>
<p><small>Apr <var data-var='date'> 2</var>, <var data-var='time'>12:24:00</var> GMT+0</small><br /><strong>Investigating</strong> -
  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..</p>

        ]]>
  </content>
</entry>

<entry>
  <id>tag:authress.instatus.com,2005:Incident/cls8w043i24660auoi3zb08i90</id>
  <published>2024-02-05T10:03:00.000+00:00</published>
  <updated>2024-02-05T10:03:00.000+00:00</updated>
  <link rel="alternate" type="text/html" href="https://authress.instatus.com/incident/cls8w043i24660auoi3zb08i90"/>
  <title>Issue logging into the Authress Management portal via SSO with Azure AD</title>

  <content type="html">
  <![CDATA[
    <p><strong>Type:</strong> Incident</p>
    
    <p><strong>Affected Components:</strong> , 
Management Portal →</p>
    <p><small>Feb <var data-var='date'> 5</var>, <var data-var='time'>10:03:00</var> GMT+0</small><br /><strong>Resolved</strong> -
  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..</p>

        ]]>
  </content>
</entry>

</feed>