Skip to main content

OAuth dla skrzynek pocztowych w AMODIT

Aktualizacja

Artykuł zweryfikowany dla wersji 260331.

Wprowadzenie

W AMODIT OAuth przy skrzynkach pocztowych pojawia się w trzech obszarach konfiguracji i w każdym z nich pełni inną rolę:

  • loguje skrzynkę procesu dla poczty przychodzącej,
  • loguje konto używane do poczty wychodzącej,
  • łączy AMODIT z aplikacją zarejestrowaną po stronie dostawcy.

Dlatego przed konfiguracją warto najpierw ustalić, czego dokładnie dotyczy dany przypadek:

  • odbioru wiadomości do procesu,
  • wysyłki wiadomości z AMODIT,
  • wspólnej konfiguracji aplikacji Google albo Microsoft.

Kiedy ten artykuł ma sens

Ten materiał jest właściwy wtedy, gdy:

  • organizacja chce używać OAuth zamiast zwykłego hasła dla skrzynek pocztowych,
  • trzeba zrozumieć, które ustawienia są wspólne, a które zależą od konkretnego procesu albo sposobu wysyłki,
  • administrator szuka właściwego punktu wejścia do dalszej konfiguracji Gmail albo Microsoft / Outlook.

To jest artykuł porządkujący. Nie zastępuje szczegółowych instrukcji dla poszczególnych dostawców.

Gdzie OAuth pojawia się w AMODIT

W praktyce OAuth dla skrzynek pocztowych w AMODIT pojawia się na trzech poziomach:

  1. jako wspólna konfiguracja aplikacji dostawcy,
  2. jako token zapisany przy skrzynce procesu,
  3. jako token zapisany w parametrze systemowym dla poczty wychodzącej.

Te poziomy są ze sobą powiązane, ale nie oznaczają tego samego.

Wspólna konfiguracja aplikacji dostawcy

Zanim AMODIT wygeneruje token dla konkretnej skrzynki albo dla poczty wychodzącej, musi wiedzieć, z jakiej konfiguracji aplikacji ma korzystać.

W tym miejscu najważniejsze są dwa parametry:

  • GoogleApplicationConfig,
  • AzureApplicationConfig.

Te parametry opisują aplikację zarejestrowaną po stronie dostawcy. Nie są jeszcze tokenem użytkownika i same nie wystarczają do odbioru albo wysyłki wiadomości. Tworzą natomiast wspólne zaplecze, z którego AMODIT korzysta później podczas logowania OAuth.

OAuth dla skrzynki procesu

Pierwszy ważny scenariusz to poczta przychodząca powiązana z konkretnym procesem.

W tym wariancie administrator:

  • ustawia sposób odbioru wiadomości,
  • wybiera serwer i protokół,
  • przechodzi do konfiguracji procesu,
  • generuje token dla skrzynki procesu.

To oznacza, że token jest związany z konkretną skrzynką przypisaną do procesu. Nawet jeśli kilka procesów korzysta z tej samej konfiguracji aplikacji Google albo Microsoft, każdy proces może mieć własną skrzynkę i własny token.

Typowe przykłady

  • Gmail dla poczty przychodzącej:
    • IMAP
    • serwer imap.gmail.com
  • Microsoft / Outlook dla poczty przychodzącej:
    • IMAP
    • EWS
    • w wybranych scenariuszach także Graph API

OAuth dla poczty wychodzącej

Drugi ważny scenariusz to poczta wychodząca.

Tutaj OAuth nie jest zapisywany przy skrzynce procesu, tylko w dedykowanym parametrze systemowym używanym przez mechanizm wysyłki. W praktyce dla opisanych już dostawców oznacza to:

  • GmailNotificationOAuthToken dla Gmail,
  • OutlookNotificationOAuthToken dla Microsoft / Outlook.

To rozróżnienie jest ważne, bo token wygenerowany dla skrzynki procesu nie zastępuje tokenu używanego później do wysyłki wiadomości. W AMODIT są to dwa różne miejsca konfiguracji i dwa różne skutki.

Co decyduje o tym, jaki wariant OAuth jest używany

Sam wybór dostawcy nie wystarcza. AMODIT rozpoznaje właściwy wariant także na podstawie:

  • protokołu,
  • serwera,
  • miejsca konfiguracji,
  • typu tokenu zapisywanego przez system.

Z punktu widzenia administratora oznacza to prostą zasadę:

  • najpierw trzeba wybrać właściwy scenariusz techniczny,
  • dopiero potem generować token i zapisywać konfigurację.

Gmail i Microsoft / Outlook: co mają wspólnego, a czym się różnią

Oba kierunki działają według podobnego modelu:

  • istnieje wspólna konfiguracja aplikacji dostawcy,
  • AMODIT generuje token OAuth,
  • token jest używany do odbioru albo wysyłki wiadomości.

Różnice pojawiają się natomiast w szczegółach:

  • Gmail używa konfiguracji GoogleApplicationConfig,
  • Microsoft korzysta z AzureApplicationConfig,
  • tokeny dla poczty wychodzącej są rozdzielone na osobne parametry systemowe,
  • zakresy autoryzacji i obsługiwane warianty połączeń nie są takie same dla obu dostawców.

Ograniczenia wsparcia dostawcy

W większości wariantów artykuł nadrzędny nie musi dopisywać osobnej noty o wsparciu dostawcy. Wyjątek warto zrobić tylko wtedy, gdy w przewidywalnym horyzoncie ma nastąpić realna zmiana.

Takim przypadkiem jest obecnie EWS dla Exchange Online.

Uwaga: Microsoft wycofuje Exchange Web Services w Exchange Online. Według aktualnej dokumentacji wyłączanie EWS rozpocznie się w październiku 2026, a pełne wyłączenie jest planowane na kwiecień 2027. Dla nowych konfiguracji warto planować przejście na mechanizmy oparte o Microsoft Graph.

Ta nota nie zmienia faktu, że wariant EWS nadal może występować w istniejących konfiguracjach i nadal warto go opisać. Oznacza jednak, że nie powinien być traktowany jako kierunek docelowy dla nowych wdrożeń opartych o Exchange Online.

Jak wybrać właściwy artykuł szczegółowy

Po zrozumieniu ogólnego modelu OAuth najlepiej przejść od razu do materiału szczegółowego właściwego dla danego scenariusza:

Warto też przejść do materiałów szerszych, jeżeli potrzebujesz pełnego kontekstu konfiguracji:

Wynik końcowy

Po przeczytaniu tego materiału administrator powinien wiedzieć:

  • gdzie w AMODIT OAuth jest konfiguracją wspólną,
  • gdzie staje się tokenem konkretnej skrzynki albo kanału wysyłki,
  • dlaczego nie wszystkie warianty należy traktować jako ten sam scenariusz,
  • do którego artykułu przejść dalej, żeby wykonać właściwą konfigurację.