OAuth 2.0 connections στο Boomi: client credentials και authorization code

Το νέο σας CRM, η πλατφόρμα ηλεκτρονικής τιμολόγησης ή το marketplace έχει REST API, και η τεκμηρίωση γράφει «OAuth 2.0». Το Basic authentication θα ήταν μία γραμμή· το OAuth φέρνει client IDs, token URLs, scopes και refresh tokens. Σε αυτό το άρθρο εξηγούμε τι συμβαίνει πίσω από αυτούς τους όρους, ποια ροή ταιριάζει σε ένα integration χωρίς επίβλεψη, και πώς τη ρυθμίζετε σε ένα HTTP Client connection στο Boomi.

Γιατί όχι να καλείτε μόνοι σας το token endpoint;

Μια συνηθισμένη πρώτη προσπάθεια είναι να στηθεί η ροή με το χέρι: μία κλήση HTTP για να πάρετε token, αποθήκευση σε ένα property, προσθήκη ως header στην επόμενη κλήση. Δουλεύει στο demo και αποτυγχάνει στην παραγωγή:

Τα tokens λήγουν. Τα access tokens ζουν συνήθως από λίγα λεπτά έως μία ώρα. Ένα μεγάλο batch, ή ένα process που τρέχει κάθε πέντε λεπτά, κάποια στιγμή θα καλέσει το API με ληγμένο token.
Η λογική ανανέωσης είναι εύκολο να γίνει λάθος. Ανανέωση πολύ συχνά πέφτει στα rate limits του token endpoint· ανανέωση πολύ αργά φέρνει σφάλματα 401.
Τα μυστικά καταλήγουν σε λάθος σημεία. Οι χειροποίητες ροές συνήθως βάζουν client secrets σε process properties, maps ή scripts, όπου αντιγράφονται και καταγράφονται στα logs.

Το pattern: το token ανήκει στο connection

Το καθαρότερο pattern είναι η ταυτοποίηση να αποτελεί μέρος του connection, όχι του process:

Process ──► Connection (client ID, secret, token, λογική ανανέωσης) ──► SaaS API

Το process λέει μόνο «κάλεσε GET /customers». Το connection παίρνει token, το προσθέτει ως Authorization: Bearer ... και το ανανεώνει όταν χρειάζεται. Τα διαπιστευτήρια βρίσκονται σε ένα component, που μπορεί να διαφέρει ανά περιβάλλον.

Επιλέξτε grant type

Ερώτηση	Grant type
Το integration ενεργεί ως ο εαυτός του, κανείς δεν συνδέεται	Client credentials
Το API δίνει πρόσβαση μόνο για λογαριασμό συνδεδεμένου χρήστη	Authorization code
Ο πάροχος προσφέρει ταυτοποίηση client με πιστοποιητικό (JWT)	JWT bearer, αν το υποστηρίζουν το API και η έκδοση του Boomi που έχετε

Για νυχτερινό συγχρονισμό τιμολογίων προς πλατφόρμα e-invoicing, η φυσική επιλογή είναι το client credentials. Για μια SaaS εφαρμογή της οποίας το API δουλεύει μόνο «ως χρήστης» (συνηθισμένο σε κάποια CRM και σουίτες γραφείου), χρησιμοποιείτε μία φορά authorization code, και το integration συνεχίζει να δουλεύει με ένα refresh token.

Πριν ξεκινήσετε: καταχωρήστε τον client

Στην κονσόλα διαχείρισης του παρόχου SaaS, καταχωρήστε μια εφαρμογή (λέγεται και app, client ή integration) και σημειώστε:

Client ID και client secret
Token URL (για παράδειγμα https://login.example-crm.com/oauth2/token)
Authorization URL (μόνο για authorization code)
Τα scopes που χρειάζεστε, για παράδειγμα customers.read invoices.write
Για authorization code: το redirect (callback) URL που πρέπει να επιτρέψει ο πάροχος. Το Boomi εμφανίζει το callback URL στην οθόνη του connection· αντιγράψτε το από εκεί αντί να το πληκτρολογήσετε.

Φτιάξτε ξεχωριστό client ανά περιβάλλον (test και παραγωγή), μόνο με τα scopes που χρειάζεται το integration.

Βήμα 1: Δημιουργήστε το HTTP Client connection

Δημιουργήστε νέο Connection component και επιλέξτε τον HTTP Client connector.
Ορίστε το URL στη βασική διεύθυνση του API, για παράδειγμα https://api.example-crm.com/v2.
Ορίστε Authentication Type σε OAuth 2.0. Εμφανίζεται μια καρτέλα ή ενότητα OAuth 2.0 με τα πεδία κάθε grant type.

Οι ακριβείς ετικέτες των πεδίων μπορεί να αλλάζουν από έκδοση σε έκδοση του Boomi, αλλά θα βρείτε τα ίδια δομικά στοιχεία που περιγράφουμε παρακάτω.

Βήμα 2α: Client credentials

Ορίστε Grant Type σε Client Credentials.
Συμπληρώστε Client ID και Client Secret.
Συμπληρώστε το Access Token URL (το token endpoint του παρόχου).
Συμπληρώστε το Scope ακριβώς όπως το τεκμηριώνει ο πάροχος. Οι περισσότεροι χωρίζουν τα scopes με κενό.
Αν ο πάροχος χρειάζεται επιπλέον παραμέτρους στο αίτημα token (κάποιοι ζητούν τιμή audience ή resource), προσθέστε τις ως επιπλέον παραμέτρους του access token.
Αποθηκεύστε και δοκιμάστε το connection ή τρέξτε ένα μικρό δοκιμαστικό process.

Με client credentials δεν υπάρχει «σύνδεση χρήστη»: ο connector ζητά token όταν το χρειάζεται, με το client ID και το secret.

Βήμα 2β: Authorization code

Ορίστε Grant Type σε Authorization Code.
Συμπληρώστε Client ID, Client Secret, το Authorization Token URL και το Access Token URL.
Συμπληρώστε το Scope. Πολλοί πάροχοι θέλουν ένα επιπλέον scope, όπως offline_access, για να εκδώσουν refresh token· ελέγξτε την τεκμηρίωση του παρόχου.
Καταχωρήστε στον πάροχο το callback URL του Boomi που εμφανίζεται στο connection.
Πατήστε το κουμπί δημιουργίας token. Ανοίγει ένα παράθυρο browser, συνδέεστε στον πάροχο με τον λογαριασμό για λογαριασμό του οποίου θα ενεργεί το integration, και εγκρίνετε τα scopes. Το Boomi αποθηκεύει τα access και refresh tokens μαζί με το connection.

Συνδεθείτε με έναν αποκλειστικό χρήστη integration (για παράδειγμα integration@company.gr), όχι με τον προσωπικό σας λογαριασμό. Αλλιώς το integration σταματά όταν φύγετε ή αλλάξει ο κωδικός σας, και κάθε αλλαγή που κάνει εμφανίζεται με το όνομά σας.

Βήμα 3: Χρησιμοποιήστε το connection σε ένα operation

Δημιουργήστε ένα HTTP Client operation για κάθε κλήση: method GET, resource path customers, response profile κ.ο.κ. Τίποτα σχετικό με tokens δεν εμφανίζεται στο operation ή στο process. Ένα απλό δοκιμαστικό process: Start (No Data) → Connector (HTTP Client, GET customers?updatedSince=2026-10-01) → Stop. Τρέξτε το σε Test Mode και ελέγξτε την απάντηση στον document viewer του shape.

Βήμα 4: Ανανέωση και λήξη token

Client credentials: ο connector ζητά νέο token όταν το τρέχον δεν ισχύει πια. Δεν αποθηκεύετε refresh token.
Authorization code: ο connector χρησιμοποιεί το αποθηκευμένο refresh token για νέα access tokens. Αν λήξει ή ανακληθεί το ίδιο το refresh token (αλλαγή κωδικού, ανάκληση από admin, πολιτική αδράνειας του παρόχου), οι κλήσεις αποτυγχάνουν μέχρι κάποιος να δημιουργήσει ξανά το token.

Μάθετε την πολιτική refresh token του παρόχου πριν την παραγωγή. Κάποια refresh tokens δεν λήγουν ποτέ, κάποια λήγουν μετά από συγκεκριμένο διάστημα, κάποια αλλάζουν σε κάθε χρήση. Γράψτε τα βήματα επανεξουσιοδότησης στο runbook.

Συνηθισμένα σφάλματα και τι σημαίνουν

Σύμπτωμα	Πιθανή αιτία
`invalid_client`	Λάθος client ID ή secret, ή secret από άλλο περιβάλλον
`invalid_grant` στην ανανέωση	Το refresh token έληξε ή ανακλήθηκε· δημιουργήστε ξανά το token
`invalid_scope`	Λάθος όνομα scope, ή δεν είναι ενεργό για αυτόν τον client στον πάροχο
`redirect_uri_mismatch`	Το callback URL του Boomi δεν έχει καταχωρηθεί ή διαφέρει ελάχιστα
`401` στις κλήσεις, ενώ το token έρχεται	Token για λάθος audience ή resource, ή λείπει scope για το endpoint
`403` μόνο σε κάποια endpoints	Πολύ στενά scopes ή δικαιώματα του χρήστη API για αυτή τη λειτουργία
Δουλεύει στο test, αποτυγχάνει στην παραγωγή	Δεν έχουν οριστεί τιμές παραγωγής στα environment extensions, ή λάθος token URL

Στο troubleshooting, κοιτάξτε το HTTP status και το πεδίο error στην απάντηση του token endpoint. Αποφύγετε logging που τυπώνει το header Authorization.

Πριν βγείτε στην παραγωγή

Χρησιμοποιήστε environment extensions για client ID, client secret και URLs, ώστε test και παραγωγή να έχουν διαφορετικούς clients. Το δείχνουμε στο Διαχείριση μυστικών και πιστοποιητικών ανά περιβάλλον στο Boomi.
Ζητήστε τα ελάχιστα scopes. Μόνο ανάγνωση όπου γίνεται.
Σημειώστε τη λήξη του secret. Πολλοί πάροχοι κάνουν τα client secrets να λήγουν (συχνά μετά από ένα ή δύο χρόνια). Βάλτε την ημερομηνία στο ημερολόγιο rotation.
Χειριστείτε τα 429. Token και API endpoints έχουν rate limits· συνδυάστε με retries όπως περιγράφουμε στο error handling και retries στο Boomi.
Τεκμηριώστε την επανεξουσιοδότηση για connections με authorization code: ποιος συνδέεται, με ποιον λογαριασμό και πώς.

Συμπέρασμα

Το OAuth 2.0 είναι λιγότερη δουλειά απ’ ό,τι φαίνεται όταν το token ανήκει στο connection: client credentials για κλήσεις μεταξύ συστημάτων χωρίς επίβλεψη, authorization code όταν το API απαιτεί χρήστη, στενά scopes και μυστικά ανά περιβάλλον. Για τη συνολική εικόνα για ταυτότητες, μυστικά και πιστοποιητικά στα integrations, δείτε τον οδηγό μας Ασφάλεια στα integrations: πρακτικός οδηγός.