---
title: "Αναφορά αυθεντικοποίησης API - bearer tokens"
description: "Πώς ταυτοποιεί αιτήματα το API του HyperCRM: η μορφή του bearer token, Firebase ID tokens έναντι OAuth access tokens, και οι κωδικοί σφαλμάτων."
canonical: "https://hypercrm.app/el/docs/api/authentication"
lang: "el"
updated: "2026-07-25"
---

_Αναφορά API / Αυθεντικοποίηση_

# Τα bearer tokens, αναλυτικά

Κάθε αίτημα στο API του HyperCRM φέρει μία κεφαλίδα: `Authorization: Bearer <token>`. Αυτή η σελίδα καλύπτει ακριβώς τι μπορεί να είναι αυτό το token, πώς απορρίπτεται μια κακοσχηματισμένη ή άκυρη κεφαλίδα, και τον συγκεκριμένο κωδικό σφάλματος για κάθε περίπτωση αποτυχίας.

[Ξεκινήστε δωρεάν δοκιμή](/dashboard) · [Πίσω στην αναφορά API](/el/docs/api)

## Η κεφαλίδα

Κάθε endpoint απαιτεί `Authorization: Bearer <token>`. Υπάρχουν δύο έγκυρα είδη token: ένα Firebase ID token από μια συνδεδεμένη συνεδρία HyperCRM, ή ένα αδιαφανές OAuth access token (`hcrm_at_...`) που εκδίδεται από τον δικό του διακομιστή εξουσιοδότησης OAuth 2.1 του HyperCRM για το endpoint MCP. Και τα δύο γίνονται δεκτά όπου αναμένεται bearer token — ο διακομιστής ελέγχει αν το token ξεκινά με `hcrm_at_` και, αν όχι, καταφεύγει σε επαλήθευση Firebase ID token.

## Χωρίς ξεχωριστό βήμα εγγραφής

Δεν υπάρχει πίνακας API-key ούτε endpoint εγγραφής για έναν καλούντα αυθεντικοποιημένο με Firebase. Στην πρώτη επιτυχή επαλήθευση μιας δεδομένης ταυτότητας Firebase, το HyperCRM βρίσκει ή δημιουργεί τον αντίστοιχο χρήστη, ιατρείο, και γραμμή ιδιοκτήτη-μέλους. Κάθε επόμενη κλήση επιλύει το ίδιο ιατρείο από το token — ένα αίτημα ποτέ δεν προμηθεύει το δικό του `practiceId`.

## OAuth access tokens

Για πελάτες MCP, το HyperCRM εκδίδει τα δικά του αδιαφανή access tokens `hcrm_at_...` και refresh tokens `hcrm_rt_...` μέσω μιας συμβατής με πρότυπα ροής OAuth 2.1: δυναμική εγγραφή πελάτη, μια οθόνη συναίνεσης βασισμένη στην ίδια σύνδεση Firebase, και υποχρεωτική ανταλλαγή κωδικού εξουσιοδότησης PKCE (S256). Τα tokens δεν είναι ποτέ JWT — αποθηκεύεται μόνο το SHA-256 hash τους — και ένα refresh token περιστρέφεται σε κάθε χρήση, ακυρώνοντας το προηγούμενο.

## Όταν αποτυγχάνει η αυθεντικοποίηση

Μια απούσα κεφαλίδα επιστρέφει `missing_authorization`· μια κεφαλίδα που δεν είναι `Bearer <token>` επιστρέφει `invalid_authorization_header`· ένα μη αναλύσιμο ή μη επαληθεύσιμο token επιστρέφει `invalid_auth_token` ή `auth_token_verification_failed`. Ένα ληγμένο token επιστρέφει `expired_auth_token`, και ένα ανακληθέν επιστρέφει `revoked_auth_token` — και τα τέσσερα είναι HTTP 401. Ένας **απενεργοποιημένος λογαριασμός είναι HTTP 403, όχι 401**: το ίδιο το token εξακολουθεί να επαληθεύεται σωστά, αλλά η ταυτότητα πίσω του είναι απενεργοποιημένη, εμφανιζόμενη ως `disabled_auth_token` ή `user_disabled` ανάλογα με ποια πλευρά το σημείωσε. Τα `unsupported_auth_provider` και `auth_provider_email_required` (και τα δύο 403) καλύπτουν παρόχους σύνδεσης που το HyperCRM δεν υποστηρίζει για πρόσβαση API. Το `auth_configuration_missing` (503) σημαίνει ότι ο ίδιος ο διακομιστής δεν έχει ρυθμισμένο έργο Firebase.

Δείτε την [πλήρη αναφορά σφαλμάτων](/el/docs/api/errors) για το πώς αυτοί οι κωδικοί εντάσσονται στον γενικό φάκελο σφάλματος, και τον [κόμβο αναφοράς API](/el/docs/api) για τις υπόλοιπες σελίδες πόρων.

## Συχνές ερωτήσεις

### Πώς προστατεύονται τα δεδομένα των ασθενών;

Τα αρχεία ασθενών κρυπτογραφούνται κατά τη μεταφορά και την αποθήκευση, τα αρχεία φυλάσσονται ιδιωτικά και σερβίρονται μέσω συνδέσμων περιορισμένης διάρκειας, ενώ κάθε αλλαγή καταγράφεται. Το προσωπικό συνδέεται με passkeys αντί για κοινούς κωδικούς.

### Μπορώ να αυθεντικοποιηθώ χωρίς συνδεδεμένη συνεδρία Firebase;

Ναι, χρησιμοποιώντας αντ' αυτού ένα OAuth access token. Το HyperCRM τρέχει τον δικό του διακομιστή εξουσιοδότησης OAuth 2.1 για πελάτες MCP: ένας πελάτης εγγράφεται μόνος του, ένας χρήστης εγκρίνει πρόσβαση μέσω οθόνης συναίνεσης βασισμένης στην κανονική σύνδεση Firebase, και ο πελάτης λαμβάνει ένα αδιαφανές access token για χρήση ως bearer token.

### Γιατί ένας απενεργοποιημένος λογαριασμός επιστρέφει 403 αντί για 401;

Επειδή το ίδιο το token εξακολουθεί να είναι έγκυρο και επαληθεύεται σωστά — ο λογαριασμός πίσω του είναι απενεργοποιημένος, κάτι διαφορετικό από ένα άκυρο ή ληγμένο διαπιστευτήριο. Το HyperCRM το αντιμετωπίζει ως πρόβλημα εξουσιοδότησης (403) αντί για πρόβλημα αυθεντικοποίησης (401), και το τεκμηριώνει ως σκόπιμη εξαίρεση.

### Λήγουν τα access tokens, και μπορούν να ανανεωθούν;

Ναι. Τα OAuth access tokens έχουν μικρή διάρκεια ζωής, και ένα refresh token μπορεί να ανταλλαγεί για νέο ζεύγος access/refresh χωρίς ο χρήστης να εγκρίνει ξανά συναίνεση. Τα refresh tokens περιστρέφονται σε κάθε χρήση, οπότε το προηγούμενο σταματά να λειτουργεί τη στιγμή που εκδίδεται νέο ζεύγος, περιορίζοντας τη ζημιά ενός διαρρεύσαντος token.